Lost sliding windows w/ DVI Syncmaster monitor

[Felix Miata]

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/