Jump to content

jvthert

Members
  • Posts

    3
  • Joined

  • Last visited

About jvthert

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    Netherlands

Recent Profile Visitors

765 profile views
  1. So a new version is dropped on the general audience without a proper test on a group of actual users? Sounds like how we developed software a decade ago. I'm sure you guys are testing it already to make sure the release will go smoothly. The question of 'supporting' is a completely different one. So is there a possibility to test a beta version before the general release? Closed beta program perhaps?
  2. Great! I'll give that a go. Btw it's not just the eset_gui, it's also the eset_tray process that triggers the discrete gpu!
  3. On MacBooks that have a dual GPU (Intel HD/Iris and Nvidia or AMD) the 'esets_gui' process forces the system to use the discrete gpu as soon as you either click on the tray icon or open the gui. After closing it the GPU is still forced into discrete mode. The problem is that this severely impacts battery life for no apparent reason. This issue is very easy to reproduce but you need gfxcardstatus (hxxp://gfx.io) to see this. The only solution to save your battery is to issue a 'sudo killall esets_gui' in order to force a restart of the process. As long as you stay away from the gui the systems keeps working with the integrated gpu. I tried reporting this to eset support but it seems they are more concerned making this process a pain in the butt. Worst was that support claimed having tried to reproduce it but this is a blatant lie. I've reliably reproduced this bug on different MacBooks. I hope someone here can chime in or relay it to product development.
×
×
  • Create New...