Paul Rogers composed on 2020-04-03 00:22 (UTC-0700): >> on it I found IceWM behaved as expected (working panning), but didn't include >> that activity in the response.
> That's probably much closer to working here than your DEs! How did you do it? I don't think I did anything that I didn't already make evident either via what I've included in thread or what I uploaded. > As far as I can see, what you documented in this post is what I have--unless > you are using framebuffers--except maybe for the xrandr --panning command. Your OS seems to be based on Ubuntu 16.04. If it wasn't, I'd expect either or both of your kernel and XServer versions to be different. But, mine is box stock. Since you compiled your own, something of significance could be different. On Buntu 16.04 I see: # ll /dev/fb* crw-rw---- 1 root video 29, 0 Apr 3 04:29 /dev/fb0 crw-rw---- 1 root video 29, 1 Apr 3 04:29 /dev/fb1 Do you get equivalent on yours?: If not, you're handicapping X potential. Your aversion to framebuffers I can't understand. To me, they are what they are. I pay no attention to them other than as required in troubleshooting assistance. VESA in the current X arena is a crude driver, developed more than a decade before KMS was conceived. AFAICT, it gets very limited attention as X evolves. X versions since KMS inception for the most part depend on younger APIs than VESA supports. I doubt X developers and driver writers do any more than the most elementary testing, very highly unlikely to touch panning, much less to ensure it can work without framebuffers or KMS. Alex's 2020-04-02 15:35 -0400 post seems to have said as much. I think he is a developer. I am nothing of the kind, just a user who spends a lot of time trying to help people solve their problems with foundational elements of Gnu Linux: bootloaders, booting, partitioning, eliminating unexpected black screens, and web usability/accessibility issues for the most part. > I went back to look at the xrandr command in your first reply to see if that > made a difference, but I couldn't figure out a proper --output parameter. The > DVI-I-1 you used didn't satisfy it. Neither it, nor the XID, are defined in > the man page! Great documentation. NOT. Alex touched this with the same comment referred to above. Panning is not supported by xrandr until version 1.2, which functionality the VESA driver does not support. VESA doesn't identify outputs that xrandr depends on. That panning worked well for you AFAICT is entirely legacy functionality, configuration via manually generated xorg.conf*. As long as you wish to continue using the VESA driver, xrandr is useless for your panning setup. If there is an Xorg or VESA bug that crept in WRT to panning configuration, you're probably going to be out of luck getting it fixed in anything resembling a reasonable time, if ever. Filing a report on https://gitlab.freedesktop.org/ might be the only way for you to make progress on this. Since you tried without success eliminating modelines from your xorg.conf*, I cannot imagine how switching from your old display to the Syncmaster caused any problem. I expected those to be the only difference. Now I think the only possible difference is either some configuration option(s) in your compilations, or a defect in the EDID of the Syncmaster, or a longshot, a bad pin in the Syncmaster connector. Distros have long been depending on automagic configuration, for well over a decade, allowing for bad things to happen to old functionality as automagic functionality evolves. Some functionality has been consciously been removed or left broken out of lack of developer and/or user interest by the evolution. I think KP+/- are part of what may have been lost. Other than abandoning your aversion to framebuffers and wedding to the VESA driver, I've about exhausted any ideas how to try to help. ATM the only other thing I can think of to try is using a box stock Ubuntu 16.04 kernel or 1.18.4 Server and whatever deps they may have that deviate from your compilations. I'd try the kernel first, as I'd expect it to be easier. Thinking outside your current box, what would serve you better I would expect to be getting (a) much larger display(s), 26" or more FHD, to enable the physical object sizes you need without resorting to low screen resolutions or legacy *manual* X or fonts setup. For the vast majority of people, X automagic configuration just works, as long as the screen is big enough, and for many, even if it's too small for comfort. While lower than optimal screen resolution is a popular method of making screen objects big enough, it's not the only way. Forcing a fake higher screen density is another, and potentially simpler to implement. Forcing 132 DPI on a 90 DPI screen makes a huge difference. That 42 dot difference (47% increase) translates to 215% in object sizes (+115%). Some DEs make it as simple as dragging a slider. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ _______________________________________________ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
