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...
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.
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?
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.
See also bug 109108. Thank you.
*** Bug 109108 has been marked as a duplicate of this bug. ***
> 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
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