Bugzilla – Bug 343858
gdm packages downloaded with control-center upgrade use resolution specified for external monitor
Last modified: 2008-05-19 09:04:17 UTC
The online update for control-center downloads a gdm update. When this is installed, the gdm screen is wrong for me. Downgrading to dvd version fixes things. The display that comes up only occupies the upper left part of the screen. It uses ~80% horizontally and maybe ~90% vertically. The left-over is blueish except for a console log window I don't recall seeing before. Possibly unrelated: on the first few logins after the upgrade I got a black screen and nothing else. This righted itself after I started a separate X server "startx -- :1".
*** Bug 343902 has been marked as a duplicate of this bug. ***
Ok, there are two problems: 1. In /etc/X11/xdm/Xsetup, the gnome2root assignment should read... gnome2root=/usr/sbin and not refer to the /opt/gnome hierarchy. 2. In /etc/sysconfig/displaymanager, I had to change DISPLAYMANAGER_RANDR_MODE_auto from its default setting of "1024x768..." to this DISPLAYMANAGER_RANDR_MODE_auto="1280x800_75 83.46 1280 1344 1480 1680 800 801 804 828" NOTE: The I derived this line from the following line in /etc/X11/xorg.conf Modeline "1280x800" 83.46 1280 1344 1480 1680 800 801 804 828 Clearly this gdm upgrade has not been well tested.
I wonder if this bug can cause fried laptop displays! Poking random mode lines into the graphics system has always been warned about. Upping severity. Btw., in /etc, doing a grep for /opt/gnome finds... init.d/xdm:PATH=$PATH:/usr/X11R6/bin:/opt/gnome/bin:/usr/openwin/bin init.d/xdm: GDM_BIN=/opt/gnome/sbin/gdm bonobo-activation/bonobo-activation-config.xml: <!-- <item>/opt/gnome2/lib/bonobo/servers</item> --> bonobo-activation/bonobo-activation-config.xml: <!-- <item>/opt/gnome2/bonobo-activation/lib/bonobo/servers</item> --> xdg/menus/applications.menu.gnome: <LegacyDir>/opt/gnome/share/gnome/apps/</LegacyDir> xdg/menus/applications.menu.gnome: <DirectoryDir>/opt/gnome/share/gnome/vfolders/</DirectoryDir> xdg/menus/applications.menu.gnome: <AppDir>/opt/gnome/share/applications/</AppDir> xdg/menus/applications.menu.gnome: <AppDir>/opt/gnome/share/gnome/ximian/applications/</AppDir>
(In reply to comment #2 from Morten Welinder) > Ok, there are two problems: > > 1. In /etc/X11/xdm/Xsetup, the gnome2root assignment should read... > > gnome2root=/usr/sbin > > and not refer to the /opt/gnome hierarchy. Arg, yes, this was part of another patch and we didn't make them available at the same time, I'll see if we can push that out asap. > 2. In /etc/sysconfig/displaymanager, I had to change > DISPLAYMANAGER_RANDR_MODE_auto from its default setting of "1024x768..." > to this > > DISPLAYMANAGER_RANDR_MODE_auto="1280x800_75 83.46 1280 1344 1480 1680 > 800 801 804 828" > > NOTE: The I derived this line from the following line in /etc/X11/xorg.conf > > Modeline "1280x800" 83.46 1280 1344 1480 1680 800 801 804 828 I think this is independent of the gdm update. I believe this is the intel driver issue. Are you using an intel chipset? > Clearly this gdm upgrade has not been well tested. Yes, bad mistake.
coolo, rudi, anja can either pull this update untill the bug 304399 piece is released or expedite bug 304399? The xorg piece has been waiting for a while their now.
Just retested, the console window flashes for me, but the greeter then covers it and I can log in and don't have the resolution issue. Additional question, are you using the standard greeter Morten?
Michael H, same questions to you if you can answer.
Thinking about how this all hangs togethers, we thought up a few more salient points: 1) Laptops? 2) Xinerama setup? 3) Docking station? 4) External monitor cloned or not? 5) As root, output of: hhwinfo --gfxcard --monitor
Thanks :) These tips from above work very well for me. About your questions: 1. Yes, it's a Transtec Levio 550 Notebook. 2. No 3. No 4. Not attached, but configured through SaX2 for cloning 5. Output after applying those patches michael-notebook:/home/michael # hwinfo --gfxcard --monitor 11: PCI 02.0: 0300 VGA compatible controller (VGA) [Created at pci.301] UDI: /org/freedesktop/Hal/devices/pci_8086_27a2 Unique ID: _Znp.3ryop4zZ9s2 SysFS ID: /devices/pci0000:00/0000:00:02.0 SysFS BusID: 0000:00:02.0 Hardware Class: graphics card Model: "Micro-Star International 945 GM" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x27a2 "945 GM" SubVendor: pci 0x1462 "Micro-Star International Co., Ltd." SubDevice: pci 0x0341 Revision: 0x03 Memory Range: 0xffe80000-0xffefffff (rw,non-prefetchable) I/O Ports: 0xec00-0xec07 (rw) Memory Range: 0xd0000000-0xdfffffff (rw,prefetchable) Memory Range: 0xffe40000-0xffe7ffff (rw,non-prefetchable) IRQ: 10 (no events) I/O Ports: 0x3c0-0x3df (rw) Module Alias: "pci:v00008086d000027A2sv00001462sd00000341bc03sc00i00" Driver Info #0: XFree86 v4 Server Module: intel Driver Info #1: XFree86 v4 Server Module: intel 3D Support: yes Extensions: dri Config Status: cfg=no, avail=yes, need=no, active=unknown 12: PCI 02.1: 0380 Display controller [Created at pci.301] UDI: /org/freedesktop/Hal/devices/pci_8086_27a6 Unique ID: ruGf.7X9h9ecL0d9 SysFS ID: /devices/pci0000:00/0000:00:02.1 SysFS BusID: 0000:00:02.1 Hardware Class: graphics card Model: "Micro-Star International Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0x27a6 "Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller" SubVendor: pci 0x1462 "Micro-Star International Co., Ltd." SubDevice: pci 0x0341 Revision: 0x03 Memory Range: 0x40100000-0x4017ffff (rw,non-prefetchable,disabled) Module Alias: "pci:v00008086d000027A6sv00001462sd00000341bc03sc80i00" Config Status: cfg=no, avail=yes, need=no, active=unknown 32: None 00.0: 10002 LCD Monitor [Created at monitor.94] Unique ID: rdCR.ko3lVhZ29yD Hardware Class: monitor Model: "SAMSUNG LCD Monitor" Vendor: SEC "SAMSUNG" Device: eisa 0x3345 Resolution: 1280x800@60Hz Size: 331x207 mm Detailed Timings #0: Resolution: 1280x800 Horizontal: 1280 1296 1344 1408 (+16 +64 +128) -hsync Vertical: 800 801 804 816 (+1 +4 +16) -vsync Frequencies: 68.94 MHz, 48.96 kHz, 60.00 Hz Config Status: cfg=new, avail=yes, need=no, active=unknown
>2. In /etc/sysconfig/displaymanager, I had to change > DISPLAYMANAGER_RANDR_MODE_auto from its default setting of "1024x768..." > to this This is done to enable projector support by default for randr12 drivers. Unfortunately gdm seems to see a Xinerama setup now and sometimes chose the wrong display to be the first display. xine and vlc have the same problem when switching to fullscreen mode. I'm not sure hwo this can be handled correctly at all. Matthias?
The weird thing is that gdm does not see this with all setups, at least with a radeon driver I'm working fine here.
Matthias for #11
As requested by Jpr on my Laptop with the following hardware 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) (prog-if 00 [VGA]) Subsystem: Fujitsu Limited. Unknown device 120e Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at d8000000 (32-bit, prefetchable) [size=128M] Memory at d0000000 (32-bit, non-prefetchable) [size=512K] I/O ports at 1800 [size=8] Capabilities: [d0] Power Management version 1 00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) Subsystem: Fujitsu Limited. Unknown device 120e Flags: fast devsel Memory at e0000000 (32-bit, prefetchable) [size=128M] Memory at d0080000 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 1 I use the i810 driver for my Xorg configuration with gdm-2.20.0-8.2 > rpm -q --changelog gdm | head -15 * Tue Nov 13 2007 - hpj@suse.de - Added gdm-tab-triggers-enter.patch, which fixes Novell bug [#334446]. * Mon Nov 12 2007 - rodrigo@suse.de - Added --with-atspi-dir to configure to get accessible login (#337428) - Updated gdm-xdm-sessions.patch to run again the /etc/X11/xdm scripts (#304399) * Mon Sep 24 2007 - hpj@suse.de - Added gdm-2.20.0-wait-for-restart.patch, which fixes Novell bug [#326281].
So it might be a specific intel card - morten do you have the intel 945 series as well?
I suggest to ask Dirk Müller, how he fixed this issue for KDE.
Dirk, can you enlighten us please? I don't think this problem is widespread enough for us to pull the update, but getting the xorg one out would be nice, as the console-in-the-corner bug affects everyone.
The console in the corner bug fix has been submitted.
My hardware info was requested at some point: laptop, Toshiba Satellite M105-S3041 SaX reports the card as Intel 945 GM.
Same happens on an FSC Amilo Si1520 with Intel 945 GM, Display is 1280*800 (according to SaX) while Screen Resolution from Control Center is fixed at 1024*768
Guys, please check your xrandr output. Thanks.
addendum comment #20 xrandr Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280 VGA disconnected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768_60 60.0* LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 261mm x 163mm 1280x800 60.0*+ 1024x768 60.0 800x600 60.3 640x480 59.9 TMDS-1 disconnected (normal left inverted right x axis y axis) TV disconnected (normal left inverted right x axis y axis)
>VGA disconnected 1024x768+0+0 [...] > 1024x768_60 60.0* So everybody understands now, why gdm defaults to 1024x768?
*** Bug 310208 has been marked as a duplicate of this bug. ***
Just thought I'd hop in here and point my finger at the intel 915GM chipset I have. Same symptoms. Find details like xrandr output under https://bugzilla.novell.com/show_bug.cgi?id=310208.
The bug happens for the same reason as bug #310208 (the gnome-panel bug): 1. gdmwm.c obtains the list of Xinerama monitors. There are overlapping monitors because we "clone" the display. However, the buggy Intel driver says that monitor 0 is a connected VGA output, while there is in fact nothing connected. 2. Places which call gdm_wm_screen_init() use GDM_KEY_XINERAMA_SCREEN to indicate the "primary" monitor they want to use. The default is zero, so GDM ends up picking the monitor size of the incorrectly-detected VGA output (1024x768 in this case).
Something like this, yes. AFAIK Dirk fixed this by using the maximum x and y values when there are overlapping monitors. Otherwise the sum of x and y values. But better let him comment himself.
Created attachment 185164 [details] gdm-bnc343858-buggy-intel-xinerama.diff Tentative patch.
Created attachment 185165 [details] gdm-bnc343858-buggy-intel-xinerama.diff Duh, I'm an idiot --- that one had an obvious bug.
Morten or anyone who experiences this problem, can you please try the gdm package here? http://download.opensuse.org/repositories/home:/federico-mena:/10.3/openSUSE_10.3/
rpm -qa | grep gdm gdm-2.20.0-9.1 gdm-lang-2.20.0-9.1 doesn't really change much. The log in screen is now full sized. Apart from that some programs maximized take a 1024*768 footprint, some take 1280*800. .
(In reply to comment #31 from Casual J. Programmer) > doesn't really change much. The log in screen is now full sized. Apart from > that some programs maximized take a 1024*768 footprint, some take 1280*800. OK, that's some progress. The panel needs a similar fix; I'll post it to bug #310208.
*** Bug 344852 has been marked as a duplicate of this bug. ***
As another downside of using the upgraded gdm package is that if I close my laptop lid for a while -- on the order to 10-15 minutes -- the machine locks up hard. (Hard enough that pressing CapsLock does nothing, for example.) No lines in /var/log/messages Going back to original gdm package fixes the problem. (== when I close the lid, the backlight goes off; when I re-open the next morning and wiggle the mouse, the screen comes back on.)
@Morten Welinder in Comment #2 you state: NOTE: The I derived this line from the following line in /etc/X11/xorg.conf Modeline "1280x800" 83.46 1280 1344 1480 1680 800 801 804 828 I don't seem to find anything alike in my /etc/X11/xorg.conf file, what am I missing here ?
(In reply to comment #22 from Casual J. Programmer) > xrandr > VGA disconnected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x > LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 261mm x > TMDS-1 disconnected (normal left inverted right x axis y axis) > TV disconnected (normal left inverted right x axis y axis) The RandR viewport model has some fundamental problems. For instances (and that is hitting all of you here) it has no notion of a "primary" screen. In fact, it has no notion of different screens at all. So the defined viewports are reported as xinerama screens in a *device* *specific* order. And it's up to the application layer to understand those xinerama reports. - They can indicate cloned desktops (in which case you (probably, but not necessarily) would want to use the biggest viewport) - They can indicated a merged desktop (in which case e.g. the panel should spread over both viewports) - They can indicate a partially merged desktop (e.g. one monitor of height 1024, one of 1050, in which case you would either want to split the panel, or have it only on one of the screens. which one? dunno) - They can indicate very weired layouts with partial overlap or not and gaps and... (no idea what to do then) Remember that there can be even more than 2 viewports, then things will get *really* interesting... HTH
*** Bug 346584 has been marked as a duplicate of this bug. ***
I've just installed Federico's gdm-2.20.0-9.1.i586.rpm package and now my gdm login screen is fullscreen again (rather than upper-left corner @ 1024x768). As Casual J. noted, maximizing windows on my desktop after login still has the 1024x768 max size issue, but JPR told me to try `xrandr --auto` and once I did that, my problem was solved. I noticed Federico was going to try adding a similar fix to gnome-panel - is this fix in the gnome-panel rpms on federico's site? My currently installed gnome-panel packages have a later version than the ones on federico's site so I was hesitant to install them. (mine are versioned gnome-panel-2.20.0-5) Also, what does the gnome-panel fix actually solve? When I originally had the login screen problem, my gnome-panel would sit at the bottom of that 1024x768 region after logging in, but I later manually moved my panel to the bottom of my actual 1440x900 screen and it has since continued to display there even after reboots/re-logins.
Running 'xrandr --auto' breaks out-of-the-box projector support. See Bug #310208 for gnome panel updates for this issue.
In addition to all the other things mentioned above I when I lock the screen; either manually or via screen saver pre sets; I cannot log back in. All I see is a blank screen. Not a black screen, a blank screen. This is especially frustrating for me because I can no longer "lock" a package; in YAST; so that it doesn't get upgraded. The software updater also doesn't explicitly state what packages are going to be updated. YAST does not diferentiate between the gdm versions on the 10.3 dvd and the updated version. Only after updating and trying it out does one know if it works. Best Regards, Peter
Created attachment 190631 [details] gtk2-bnc343858-buggy-intel-xinerama.diff This patch is for gtk2. It makes gdkscreen-x11.c sanitize the monitor geometries, so that apps that use GdkScreen to fetch the monitor data will behave correctly.
Created attachment 190632 [details] gdm-bnc343858-buggy-intel-xinerama.diff This makes GDM use GdkScreen to fetch monitor information instead of poking Xinerama directly. It depends on the patch to gtk2 described above.
Created attachment 190636 [details] metacity-bnc343858-buggy-intel-xinerama.diff Patch for metacity. It wants to use Xinerama directly, so this one doesn't depend on the gtk2 package.
There are packages of gdm, gtk2, and metacity for testing here: http://www.gnome.org/~federico/misc/bnc343858/ Can you please download them and give them a try?
Hmm, I've tested your packages and here is result: gdm + gtk2 + metacity installed: gnome won't start (I can see only wallpaper and .xsession-errors says something about bad assertion with xinerama) only gdm - nothing changes, just as the same as before Anyway, after playing a bit (installing your packages, then installing distro's defaults...) my system becomes so messed up that i have to reinstall it: almost a half of icons cannot be displayed, and gdm starts in safe mode. xsession errors says something like this: GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/etc/gtk-2.0/gdk-pixbuf.loaders': No such file or directory So these packages don't work for me and they've broken my system.
Ugh, that's really bad... Pavel, can you please attach your .xsession-errors?
Federico: Sorry, cannot attach it you because i'm running fedora now and no longer have this file.
Setting to ASSIGNED again, since Pavel switched to a different Linux distribution and therefore cannot provide feedback any more.
*** Bug 361107 has been marked as a duplicate of this bug. ***
I have an intel chipset gfx card and encounter also this issue.
ANybody working on this bug? Once the system updates are applied after a fresh install the resolution is crapped :S There is no activity since... 25/11 2007! =(
> There is no activity since... 25/11 2007! =( Well, there is, but affected users either didn't provide feedback for the new packages or already switched to different Linux distributions. :-(
I encounter the bug on a freshly installed and lately updated x64 system, please let me know which files or output you would desire to resolve the problem.
Stefan: Hmm, I think I'm not the only who encountered this issue, but as I can see I was the only one who tested that packages and provided some (but not very detailed) info.
I don't think that very many people felt like testing the "packages" after reading Pavel's experience in comment #45. At least I didn't, sorry guys, I'm sure you can do better.
comment 53: Theodoros, could you follow comment 44: > There are packages of gdm, gtk2, and metacity for testing here: > http://www.gnome.org/~federico/misc/bnc343858/ > Can you please download them and give them a try? comment 55: Well, it might have been a local problem depending on Pavels config, or it might be a general one. Without the log files it will be hard to say so.
I downloaded the packages, right click and install while all were selected (architecture i586 on my 2nd laptop which also encounters the problem) and uppon restart the computer freezes before the loading window, gnome desktop opens. Then my only choice is the power off button ...
I encounter the bug on both i586 and x64 architecture installations. Both laptops have an intel graphics chipset if that helps.
I'm having the same issue with openSUSE 10.3 Gnome and my Intel 945 GM. Any hopes this will be fixed for openSUSE 11 :) ? KDE works fine for some reason as stated in other comments . . . As is, I issued 'sax2 -r -m 0=i810' per the release notes to put me back on the old driver which works fine. . . Thanks for all the time and hard work!
I've removed the packages mentioned in comment #45, as they make things worse. In about a week and a half we'll have a bug-week to fix multiscreen bugs and this issue in particular. Theodoros and Blair, do you both have openSUSE 10.3 installed? Would you be willing to help test things at that time?
Hello Federico! I have OpenSUSE 10.3 with the same problem, and am willing to help during that week, too.
Federico: I can test packages at that time but only in one machine as I need something to work on :) Good luck with the bug-hunting!! I m sure there is a whole bunch of people out there waiting for this to be solved
Yes I am running 10.3 and could help test. Unfortunately, unlike Theodoros (I'm jealous), I only have one machine and it's my work lappy. I can back up everything and hammer it though! :) Anything to get things working right for everyone . . .
I am running opensuse 10.3 on two laptops and I'd like to help. One is a Toshiba P205-S6347 w/a 17" screen and the other is a Thinkpad T61 6465-CTR w/a 15.4" screen. Both have the problems described and I can disable Ygl easily enough to test the packages. Both also have the Intel video chip. The Toshiba has an Mobile Intel® Graphics Media Accelerator X3100 which I think is the 965? and the T61 has the Intel PM965/GM965 chip. Best Regards, Peter
In Comment #24 Bug 310208 has been marked as a duplicate of this bug. But there seems to be activity still going on. Please recheck.
Re Comment #60 I can assist too, but I am at 11.0 alpha2 currently.
So, the GTK+ patch seems to fix the issue for gnome-panel (bug 310208). I'll look at the gdm patch now.
I can confirm that the GTK+ patch resolves the gnome-panel issue. All working as expected now.
I can also confirm that the GDM patch resolves the GDM issue of not displaying correctly. 2 down 1 to go :)
One thing that popped up on my eyes after reading the complete backlog: (In reply to comment #26 from Federico Mena Quintero) > 1. gdmwm.c obtains the list of Xinerama monitors. There are overlapping > monitors because we "clone" the display. However, the buggy Intel driver says > that monitor 0 is a connected VGA output, while there is in fact nothing > connected. Actually, it doesn't, the VGA output is *driven*, but not connected. There's a difference, the VGA output drivers pump out the signal, but the driver correctly assumes that there's nothing connected. OTOH I don't know your setup, so it might be that the driver wrongly identified some connection. The VGA port is pretty stable regarding load detection, though, and I haven't seen wrong connection detections so far. 2nd, we probably won't set DISPLAYMANAGER_RANDR_MODE_* to "auto" any longer in future products, this just made too many problems. We'd rather like to see both krandrtray and resapplet be able to switch on/off outputs dynamically, and if it is by calling 'xrandr --auto' when selecting a 'Redetect Outputs' menu entry or similar. Currently RandR automatically does something similar (at least on Intel) when the current configuration is asked for, so at least with krandrtray just selecting the same resolution again sort-of works.
(In reply to comment #70 from Matthias Hopf) > or similar. Currently RandR automatically does something similar (at least on > Intel) when the current configuration is asked for, so at least with krandrtray > just selecting the same resolution again sort-of works. Please note that behavior of RandR in these corner cases is changing almost on a daily basis, so a general means of calling 'xrandr --auto' or embedding the functionality likewise would be deeply appreciated.
*** Bug 372057 has been marked as a duplicate of this bug. ***
Matthias: I quickly looked if other distros were affected by this bug too. In Ubuntu, I found some bugs and after digging a bit, they fix things with patches in the intel drivers. See the patches at http://patches.ubuntu.com/by-release/extracted/ubuntu/x/xserver-xorg-video-intel/2:2.2.1-1ubuntu5/ (08_945gm_quirk.diff is an example). Do you think we should fix this at the X level with patches like this or at the toolkit level (like the gtk+ patch is doing)?
Given the state of RandR this is purely a toolkit issue. Real multihead support is new in Xorg (well, available for some time now, but full RandR support wasn't exposed in our product for quite some time), so additional functionality has to be implemented. One could argue about RandR not being explicit enough, but the extension has been specified for a long time now, and nobody complained. So we have to deal with this imperfect world until the next version with improved information is standard (several years from now, my estimation).
The gtk+ bug is now filed upstream as http://bugzilla.gnome.org/show_bug.cgi?id=523408
I've submitted gtk+ and gdm packages with the patches. (well, gdm is being blocked by a technical detail right now) GDM upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=523403 (patch already committed upstream) Only problem left is metacity.
*** Bug 375280 has been marked as a duplicate of this bug. ***
I‘ ve got the same problem I guess. (opensuse10.3, gdm&gnome, update and then this problem) I can manage it opening grandr and checking the Off-checkbox. But even if I do that as root - every xstart starts with the wrong behaviour again. How to say randr OFF forever (or at least as long as I don‘t say ON again)? That would be a solution for me. sax2 says: Intel 945 GM LPL LGPHILIPSLCD LCD MONITOR on HP Compaq nx 7400 xrandr says: Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280 VGA disconnected 1024x768+0+0 (normal left inverted right) 0mm x 0mm 1024x768_60 60.0* LVDS connected 1280x800+0+0 (normal left inverted right) 330mm x 210mm 1280x800 60.1*+ 60.0 58.9 1152x768 54.8 1024x768 60.0 60.0 58.8 800x600 60.3 60.0 56.2 58.7 640x480 59.9 TV disconnected (normal left inverted right)
PS Maybe on http://wiki.debian.org/XStrikeForce/HowToRandR12 I could find a solution, but it‘s to difficult for me (my english and computer-knowledge is to low). Also I don‘t know where to edit xorg.conf at all (in etc... or in var...?). why there are so many files???) /etc/X11/xorg.conf /etc/X11/xorg.conf.install /etc/X11/xorg.conf.md5 /etc/X11/xorg.conf.saxsave /var/lib/sax/xorg.conf /var/lib/sax/xorg.conf-suse10-3 /var/lib/sax/xorg.conf.first /var/lib/sax/xorg.conf.md5
(In reply to comment #73 from Vincent Untz) > Matthias: I quickly looked if other distros were affected by this bug too. In > Ubuntu, I found some bugs and after digging a bit, they fix things with patches > in the intel drivers. See the patches at > http://patches.ubuntu.com/by-release/extracted/ubuntu/x/xserver-xorg-video-intel/2:2.2.1-1ubuntu5/ > (08_945gm_quirk.diff is an example). This one is about the TV encoder not being able to find out that nothing is connected. We either have the according option added to xorg.conf, or we haven't seen this issue yet. But I'm very inclined to disable TV output support in the intel driver completely, and adding the option to xorg.conf by a SaX profile is the easier solution if it deems necessary.
(In reply to comment #79 from Sebastian Zschernig) > How to say randr OFF forever (or at least as long as I don‘t say ON again)? > That would be a solution for me. You don't have to, just set DISPLAYMANAGER_RANDR_MODE_VGA="" in /etc/sysconfig/displaymanager, as a temporary solution. (In reply to comment #80 from Sebastian Zschernig) > Maybe on > http://wiki.debian.org/XStrikeForce/HowToRandR12 > I could find a solution, but it‘s to difficult for me (my english and > computer-knowledge is to low). Probably not. That you get this issue even with no external monitor connected is *very* SuSE specific. > Also I don‘t know where to edit xorg.conf at all (in etc... or in var...?). > why there are so many files???) > /etc/X11/xorg.conf This one. Though theoretically you should not need to touch it ;-) > /etc/X11/xorg.conf.install This is a safe configuration, using fbdev. Used during installation. > /var/lib/sax/xorg.conf These are SaX-only files.
(In reply to comment #41 from Federico Mena Quintero) > Created an attachment (id=190631) [details] > gtk2-bnc343858-buggy-intel-xinerama.diff > * gdk/x11/gdkscreen-x11.c (check_xfree_xinerama): Sanitize the > monitors that we get from XineramaQueryScreens(). > (sanitize_monitors): Workaround for an Intel 915GM driver bug, > where it will return that a VGA output is connected to a laptop, > even though it isn't. In the case of just two overlapping > monitors ("laptop plus cloned external display"), simulate that we > have only *one* monitor. This is not an intel driver bug. It's the result from having a monitor with lower resolution than the internal display, and the current code going for the first available xinerama screen (for which it shouldn't have any preference). This comment is very misleading, so I'd rather like to have it rephrased.
(In reply to comment #83 from Matthias Hopf) > This is not an intel driver bug. It's the result from having a monitor with > lower resolution than the internal display, and the current code going for the > first available xinerama screen (for which it shouldn't have any preference). I see this issue on my laptop and I only have one display and no dual head setup. So I don't this is completely accurate. And for what it is worth, the issue goes away when I turn on XGL.
It *is* accurate. The external monitor is enabled by default as 1024x768 on SuSE, as it already has been explained multiple times. This is due to having external monitor support out-of-the-box, and should be removed ASAP when the resolution switching tools (aka: RandR tools) have a possibility for auto-detecting all attached monitors. Which is trivial to implement (call 'xrandr --auto') but hasn't been done yet. Xgl doesn't forward the xinerama emulation configs from RandR completely AFAIK, that's why you don't see that there. But this might change with Xgl having full RandR 1.2 support now. Might.
(In reply to comment #82 from Matthias Hopf) > (In reply to comment #79 from Sebastian Zschernig) > > How to say randr OFF forever (or at least as long as I don‘t say ON again)? > > That would be a solution for me. > > You don't have to, just set > DISPLAYMANAGER_RANDR_MODE_VGA="" > in /etc/sysconfig/displaymanager, as a temporary solution. Thank you very much, that helps!!
*** Bug 375964 has been marked as a duplicate of this bug. ***
So what can we expect for 11.0?
Comment # 82 helped me to fix the issue. Thanks.
*** Bug 375171 has been marked as a duplicate of this bug. ***
(In reply to comment #88 from Ted Bullock) > So what can we expect for 11.0? There's just one bug left at the moment, with maximized windows in metacity. We'll look at it. Everything else should already be fixed in factory.
A couple of things. * Is it worthwhile to create a new bug for 11.0? * After updating to latest factory (close to Beta 1, I suppose), running sax2 -r builds a xorg.conf for my laptop (Intel 855gm) that correctly uses the onboard native LVDS panel resolution (1280x800). * I cannot get xrandr to extend my desktop to an external monitor. This is probably the same thing mentioned at (http://lists.freedesktop.org/archives/xorg/2007-April/023703.html). Do we have a tracking bug for this? * Also which bug is it that we are looking at below? Can we add it as a dependency of this bug? (In reply to comment #91 from Vincent Untz) > There's just one bug left at the moment, with maximized windows in metacity. > We'll look at it. Everything else should already be fixed in factory.
> * Also which bug is it that we are looking at below? Can we add it as a > dependency of this bug? > (In reply to comment #91 from Vincent Untz) > > There's just one bug left at the moment, with maximized windows in metacity. > > We'll look at it. Everything else should already be fixed in factory. > Oh, I certainly hit this bug :) So what is the tracking number?
(In reply to comment #92 from Ted Bullock) > A couple of things. > > * Is it worthwhile to create a new bug for 11.0? I believe this bug is more or less tracking the status in 11.0 now. > * After updating to latest factory (close to Beta 1, I suppose), running sax2 > -r builds a xorg.conf for my laptop (Intel 855gm) that correctly uses the > onboard native LVDS panel resolution (1280x800). > > * I cannot get xrandr to extend my desktop to an external monitor. This is > probably the same thing mentioned at > (http://lists.freedesktop.org/archives/xorg/2007-April/023703.html). Do we > have a tracking bug for this? No idea. > * Also which bug is it that we are looking at below? Can we add it as a > dependency of this bug? > (In reply to comment #91 from Vincent Untz) > > There's just one bug left at the moment, with maximized windows in metacity. > > We'll look at it. Everything else should already be fixed in factory. As far as I know, we're tracking the metacity bug here too, since the root cause of the bug is the same.
*** Bug 382224 has been marked as a duplicate of this bug. ***
Created attachment 209970 [details] Patch for gtk+ in openSUSE 10.3 Here we go with backporting things to 10.3.
Created attachment 209971 [details] Patch for gdm in openSUSE 10.3 Note that those patches are most probably the same as the ones federico attached earlier, but I'm attaching them for clarity (I've rebuilt the 10.3 packages with them, to be sure they apply).
Andreas: I'd like a swamp id for the patches in comment #96 and comment #97. Both patches have been used in factory for quite some time and solve the reported issues (gdm and some apps like gnome-panel not using the whole screen on some hardware).
Not quite sure why NEEDINFO wasn't set to Andreas. Andreas, please see comment #98 :-) Thanks!
Okay, it seems it's not Andreas that should be in NEEDINFO. I blame some doc I had... Third try for the swamp id.
I've created bug 385553 for the metacity issue. Fixed gtk2 and gdm packages have been submitted for 10.3, so closing.
*** Bug 389003 has been marked as a duplicate of this bug. ***
10.3 iupdate was released