Various sources (e.g. IRC) have led me to believe that `vblank_mode` should be a settable option via ~/.drirc; however, it doesn't seem like this is the case to me. A demonstration: <driconf> <device screen="0" driver="radeonsi"> <application name="Default"> <option name="vblank_mode" value="0" /> </application> </device> </driconf> I made this from the ~/.drirc skeleton created by `driconf`. Curiously, the `vblank_mode` setting was also absent from that skeleton, but I added it manually. (It's also absent from the GUI - although a friend of mine says he has the option in his driconf interface!) As expected, this option seems to have no effect - I still get vsync in all tested applications (e.g. glxgears). I can override it manually by using the environment variable vblank_mode, e.g. `vblank_mode=0 glxgears`. This *does* work, although it doesn't explain why this option is seemingly ignored from ~/.drirc. More worrying is the fact that the actual source code (dri3_set_swap_interval) uses configQuery("vblank_mode") to get this value, so it should pull it from both XML and the environment, right? If this is not expected behavior, I can try stepping through the `configQuery` function in gdb; but I thought I'd ask first in case this is a known or easily explained issue. Mesa version is 17.2.0, kernel version is 4.12.4, device is a Sapphire RX 560.
Hi, The problem seems to be with the `driver="radeonsi"' part (the screen attribute is not used when driver is present). It seems that there is a bug and an incorrect driver name "loader" is passed to the xmlconfig machinery. For a quick work-around, just remove both screen and driver attributes, unless you want to restrict your setting to a specific driver/screen.
Verifying that your work-around does, indeed, work around the issue.
Was too fast. The passed driver name is not "loader" but "dri2". And I think it's intentional, since vblank_mode is not an option of a device driver but of the dri infrastructure. I will let the more experienced developers judge this bug report, but I would say it's NOTABUG.
IMHO, while there is a certain internal logic to it, having to put driver="dri2" here is surprising and bad usability. I'd say this is a valid bug, and should be fixed.
At the very least, it's a bug in driconf that it doesn't show up in the GUI.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1018.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.