Bug 108970

Summary: kicker confused in multi-screen configuration
Product: [Plasma] kicker Reporter: mi+kde
Component: multiscreenAssignee: Aaron J. Seigo <aseigo>
Status: RESOLVED UNMAINTAINED    
Severity: normal CC: finex
Priority: VLO    
Version: 3.4.1   
Target Milestone: ---   
Platform: unspecified   
OS: FreeBSD   
Latest Commit: Version Fixed In:
Attachments: output of `xdpynfo'

Description mi+kde 2005-07-12 06:12:17 UTC
Version:           3.4.1 (using KDE 3.4.1, compiled sources)
Compiler:          gcc version 3.4.2 [FreeBSD] 20040728
OS:                FreeBSD (amd64) release 5.4-STABLE

I have a "weird" setup now. Two video cards, four monitors.

One pair of monitors are joined into a single screen (through radeon driver's "MergedFB" option). This is my screen :0.1.

Screens :0.0 and :0.2 are independent and both attached to the second (dual output) video card. No MergedFB there, because the monitors are entirely different.

The screen :0.0 is 1280x1024, the merged :0.1 is 2560x1024 and the :0.2 is 1400x1200.

KDE seems to think, Xinerama is enabled on _both_ :0.1 (where MergedFB is, indeed, aiking to Xinerama, and where kicker occupies the bottom of only one of the monitors) and :0.2 (where there is nothing like Xinerama, and where asking kcontrol to "identify" screens only shows the big "1" on one monitor -- the big 1400x1200 one).

The biggest trouble stemming from this confusion, is, that the kicker running on this big monitor (screen :0.2) seems to think, the monitor size is 1280x1024 -- like it is on :0.0 -- the kicker's panel is slightly above the bottom (by 1400-1280=120 pixels) and slightly shorter than the screen (by 1200-1024=176 pixels, I guess) -- it, sort of, hangs in mid-air.

Could somebody have confused the relationship between X-screens and parts of Xinerama, or something?

Of course, with the arrogance of most of today's software, the program resists any attempts to manualy resize/reposition it...
Comment 1 Aaron J. Seigo 2005-07-12 06:28:56 UTC
so you have both xinerama and dual head set up on the same instance of X? heh. honestly, this kind of configuration has about 0 chance of getting debugged unless someone with a passion for oddball multiscreen setups comes along who's willing to hack on this.
Comment 2 mi+kde 2005-07-12 14:57:22 UTC
It is not Xinerama, it is a MergedFB. It is, of course, very nifty, that its two moniroes are recognized as such.

Screens :0.0 and :0.2 ARE NOT Xinerama based.

=honestly, this kind of configuration has about 0 chance of getting debugged

Well, I appreciate the honesty...

Can you tell me, where in the code does kicker decide, what the screen is?

Can you tell me, where in the code does kicker (or anything) decide, whether or not the screen has Xinerama enabled?
Comment 3 mi+kde 2005-07-12 17:33:28 UTC
Created attachment 11781 [details]
output of `xdpynfo'

This is the output of xdpyinfo run on the screen :0.2. It lists all of the
displays and extensions. Running it on the others screens produces nearly
identical output -- differing only in the "name of display" and "default screen
number" entries.

Hope, this helps.
Comment 4 mi+kde 2005-07-14 23:23:10 UTC
See also bug 109108. Thank you.
Comment 5 Aaron J. Seigo 2005-07-15 01:42:34 UTC
*** Bug 109108 has been marked as a duplicate of this bug. ***
Comment 6 Aaron J. Seigo 2005-08-14 01:01:11 UTC
> Can you tell me, where in the code does kicker decide, what the screen is

for multihead? in kdebase/kicker/main.cpp
for xinerama? in several places. for instance, where ever it checks QApplication::desktop()->screenGeometry(int) 

> whether or not the screen has Xinerama enabled

wherever it checks for desktop()->screenNumber(QWidget*) or desktop()->numScreens()... 

this happens primarily in classes in kdebase/kicker/kicker/core
Comment 7 FiNeX 2009-09-08 00:00:27 UTC
Kicker is no more mantained and all bugs/wishes will not be fixed/implemented in KDE3. A list of the most interesting/unresolved issues which is still valid for KDE4 has been created. Before reopening old kicker bugs on KDE4 Plasma, please try the new KDE 4.3.1, check the current behaviour and, only if you find new bugs or if you need a particular feature, open a new bug report.

Remember that KDE 4 is a full rewrite of KDE 3 so some old features will not be re-implemented because the behaviour has be changed a lot on some sides.

Thanks for the comprehension and enjoy the new KDE 4!

-- 
FiNeX & D. Andres