Framebuffer size can be too small for all screens in intermediate steps #404
Labels
Comments
|
Agreed, using a framebuffer size that fits both old and new configuration for everything but the last command seems like the best approach here. |
|
I don't know much about XRandR, but these lines in L928-933 at the beginning: fb_dimensions = get_fb_dimensions(new_configuration)
try:
fb_args = ["--fb", "%dx%d" % fb_dimensions]
except:
# Failed to obtain frame-buffer size. Doesn't matter, xrandr will choose for the user.
fb_args = []L983-986 after the "auxiliary pre-changes": # Starting here, fix the frame buffer size
# Do not do this earlier, as disabling scaling might temporarily make the framebuffer
# dimensions larger than they will finally be.
base_argv += fb_argsL1021-1025 at the very end: # Adjust the frame buffer to match (see #319)
if fb_args:
argv = base_argv
if call_and_retry(argv, dry_run=dry_run) != 0:
raise AutorandrException("Command failed: %s" % " ".join(map(shlex.quote, argv)))Given the initial comment that failing to obtain the frame-buffer size doesn't matter as xrandr will choose for us, would it be possible to only set the frame-buffer size at the very end with the last command and keep it flexible in the meantime? That would look like this: #408 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm running into an issue when applying a configuration if the current configuration has an output outside the framebuffer of the target configuration. I'll illustrate with ARandR screenshots and show the offending commands afterwards:
Screenshots
Initial configuration:
Target configuration:
The first xrandr command autorandr attempts to run targets only the two upper to screens, but already resizes the framebuffer to the final size even though this will leave the lower screen outside the framebuffer like this:
XRandR commands
A
--dry-runshows me that autorandr wants to run these three xrandr commands:The first one fails with this error:
Possible solution
I think the value
--fbargument should not be the size of the target configuration, but should be large enough to include all outputs that will be adjusted in later xrandr calls, but have not yet been adjusted. In my case, everything works fine, if I replace the--fb 6560x2560in the first command with--fb 4000x4160which is just large enough to hold every output.I'm guessing that the
single-passoption referenced in #88 would also work, but if it doesn't work for many drivers, that's probably not the best solution.The text was updated successfully, but these errors were encountered: