[ icewm-Bugs-2797175 ] taskbar does not respect primary screen with fglrx

Bugs item #2797175, was opened at 2009-05-27 06:52
Message generated for change (Comment added) made by wosc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100031&aid=2797175&group_id=31

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: icewm-1.3
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Wolfgang Schnerring (wosc)
Assigned to: Nobody/Anonymous (nobody)
Summary: taskbar does not respect primary screen with fglrx

Initial Comment:
icewm version: both 1.2.38pre1 and 1.3.4pre2
context: fglrx driver and xrandr.
Actual result: Taskbar stretches over both screens.
Expected result: taskbar should only be visible on the primary screen.

Reason: fglrx also reports disconnected screens, but YDesktop::updateXineramaInfo only stores the actually connected ones in xiInfo. However, their screen_number is set to whatever was reported by the driver. In my case: 0=LCD, 1=disconnected TV, 2=CRT.

YDesktop::getScreenGeometry restricts screen numbers you can ask for to how many entries there are in xiInfo, so in my case it is impossible to get the geometry of the CRT-screen (which I would like to use as primary), since it has the number 2, but there are only 2 entries in xiInfo (so allowed to ask are 0 and 1). Thus, the geometry of the whole desktop is returned when asking for the primary screen, so the taskbar stretches over both.

Proposed solution: do not restrict which screen numbers can be asked for (see attached patch against 1.3.4pre2). This change is both safe and backwards compatible. All it does is remove the short-circuiting. If you do ask for a screen that does not exist (say, screen number 25), it will simply loop through all screens it knows about before concluding it doesn't exist.

----------------------------------------------------------------------

>Comment By: Wolfgang Schnerring (wosc)
Date: 2009-05-27 08:20

Message:
The solution to the problem gets a little more complicated than I
orginially thought.

fglrx in my case uses screen numbers 135 and 136 (not 0, 1, 2 as I wrote
previously), which is larger than the allowed range for the preference
XineramaPrimaryScreen. That can be solved by increasing the range in
src/default.h, from 63 to, say 255. If I then directly specify
XineramaPrimaryScreen=136, all works as expected.

Using XRRPrimaryScreenName = CRT1, however, does not work, since
YDesktop::updateXineramaInfo assigns xineramaPrimaryScreen using the
*index*, not the screen number.

I'll give up trying to come up with patches now, since it seems there is a
larger conceptual misconception going on here, as to which numbers shall be
used for identifying screens (their "screen number" reported by the driver,
or their index in xiInfo, or...), and I have a feeling that's going a bit
over my head -- I don't actually know much about the underlying protocols
and stuff, I was just hacking my way through the code to get it working for
me again.

If someone with more insight wants to give some directions how this should
be resolved the Right Way(tm), I'd be happy to do some work on it, though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100031&aid=2797175&group_id=31

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com