A big "Thank you" for xserver-xorg-video-mach64, version 6.9.5-1
Dear Maintainers, I just wanted to drop a quick note to say "Thank you" for package xserver-xorg-video-mach64, version 6.9.5-1. My video chipset is ATI Rage XL [1002:4752], and of course it uses the mach64 driver. The driver has never worked properly for me. I have had many annoying rendering problems with it. Often I would have to switch to a text console (Ctrl+Alt+F1) and then back to the graphical desktop (Alt+F7) to force a screen redraw. But no more! Starting with 6.9.5-1, everything now works perfectly. I have gone out of my way to try to make it fail, but I can't. Even with multiple overlapping windows, there are no more rendering problems. Isn't it nice when things just work? Thanks again for all your efforts. I am very happy! Please pass along my good pleasure to the appropriate upstream personnel as well. Regards, -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1925593605.13965439.1437011823186.javamail.zim...@wowway.com
Bug#787144: MACH64(0): Cannot read int vect
I realize that this bug report is already closed, and that a fixed version is available. But I just wanted to call attention to the fact that the VESA driver is not the only driver which can get this error. I got the same error with the MACH64 driver, as follows: (EE) MACH64(0): Cannot read int vect Do you suppose that any non-KMS-based driver will have the same problem? Installing the 2:1.17.2-1 version of xserver-xorg-core (and xserver-common) fixed the problem for me as well. Please CC me if you reply, as I am not subscribed to this bug report. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1045771426.12547546.1436832580660.javamail.zim...@wowway.com
Bug#726585: Chipset ATI Rage XL PCI [1002:4752] fails during initialization with MACH64 driver
On Sun, 13 Jul 2014 08:37:01 -0400 (EDT), Julien Cristau wrote: > On Sat, Mar 1, 2014 at 11:23:38 -0500, Stephen Powell wrote: >> >> I have had to go back to using >> >>Option "ExaNoComposite" "true" >> >> in the xorg.conf file. Although the patch you provided does prevent a crash >> during initialization, a number of rendering problems remain. Usually, I >> can recover the proper appearance of the screen by switching to a text >> console with Ctrl+Alt+F1, then switching back to the graphical console with >> Alt+F7; but after doing this a number of times, the X server usually crashes. >> Clearly there are other rendering problems with EXA not fixed by the patch. > > This will have to be addressed upstream. Actually, the above-described problem seems to have more to do with the non-device-specific portions of the X server. Subsequent maintenance to jessie has fixed this problem. I am back to disabling the ExaNoComposite option again. I still have some minor rendering problems, particularly after the screen saver has kicked in, but the server doesn't crash anymore. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1109149809.13267.1405293893375.javamail.r...@md01.wow.synacor.com
Bug#726585: Chipset ATI Rage XL PCI [1002:4752] fails during initialization with MACH64 driver
I have had to go back to using Option "ExaNoComposite" "true" in the xorg.conf file. Although the patch you provided does prevent a crash during initialization, a number of rendering problems remain. Usually, I can recover the proper appearance of the screen by switching to a text console with Ctrl+Alt+F1, then switching back to the graphical console with Alt+F7; but after doing this a number of times, the X server usually crashes. Clearly there are other rendering problems with EXA not fixed by the patch. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1724748740.101333.1393691018872.javamail.r...@md01.wow.synacor.com
Bug#726585: Chipset ATI Rage XL PCI [1002:4752] fails during initialization with MACH64 driver
On Sat, 19 Oct 2013 05:51:30 -0400 (EDT), Julien Cristau wrote: > > Can you check if > http://cgit.freedesktop.org/xorg/driver/xf86-video-mach64/commit/?id=2c83b465b336a012f2d2716940bf483358388000 > fixes the crash? Yes, it does! Nice work, Julien! Even without the ExaNoComposite option in effect, the driver works fine if the above patch is applied! -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/156049651.3766243.1382282683132.javamail.r...@md01.wow.synacor.com
Bug#726585: Chipset ATI Rage XL PCI [1002:4752] fails during initialization with MACH64 driver
I have discovered that this bug can be circumvented by using the following option in the "Device" section of the xorg.conf file: Option "ExaNoComposite" "true" -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/149147742.3758380.1382203607303.javamail.r...@md01.wow.synacor.com
Bug#726585: Chipset ATI Rage XL PCI [1002:4752] fails during initialization with MACH64 driver
Package: xserver-xorg-video-mach64 Version: 6.9.4-1+b1 Severity: important After upgrade of package xserver-xorg-video-mach64 from version 6.9.1-2 (which was working for me) to version 6.9.4-1+b1, I receive the following error during X initialization (extracted from /var/log/Xorg.0.log): drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: node name is /dev/dri/card0 [drm] failed to load kernel module "mach64" (EE) [drm] drmOpen failed (EE) MACH64(0): [dri] DRIScreenInit Failed I'm not sure if this is a fatal error, as the driver keeps on ticking. But then later I get this: (EE) Backtrace: (EE) 0: /usr/bin/Xorg (xorg_backtrace+0x49) [0xb7761f99] (EE) 1: /usr/bin/Xorg (0xb75c2000+0x1a3d24) [0xb7765d24] (EE) 2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xb75a040c] (EE) 3: /usr/lib/xorg/modules/drivers/mach64_drv.so (0xb6f68000+0x1de95) [0xb6f85e95] (EE) 4: /usr/lib/xorg/modules/drivers/mach64_drv.so (0xb6f68000+0x1df96) [0xb6f85f96] (EE) 5: /usr/lib/xorg/modules/libexa.so (0xb6592000+0xdc19) [0xb659fc19] (EE) 6: /usr/lib/xorg/modules/libexa.so (0xb6592000+0xeb7e) [0xb65a0b7e] (EE) 7: /usr/bin/Xorg (0xb75c2000+0x1232ce) [0xb76e52ce] (EE) 8: /usr/bin/Xorg (CompositePicture+0x299) [0xb76da0a9] (EE) 9: /usr/bin/Xorg (0xb75c2000+0x11c7f5) [0xb76de7f5] (EE) 10: /usr/bin/Xorg (0xb75c2000+0x11879d) [0xb76da79d] (EE) 11: /usr/bin/Xorg (0xb75c2000+0x3c35d) [0xb75fe35d] (EE) 12: /usr/bin/Xorg (0xb75c2000+0x2a38a) [0xb75ec38a] (EE) 13: /lib/i386-linux-gnu/i686/cmov/libc.so.6 (__libc_start_main+0xf5) 0xb719e8c5] (EE) 14: /usr/bin/Xorg (0xb75c2000+0x2a768) [0xb75ec768] (EE) (EE) Segmentation fault at address 0xc (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. (EE) (EE) Server terminated with error (1). Closing log file. which causes the X server to fail initialization. "lspci -nn" produces the following output: 05:03.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Rage XL PCI [1002:4752] (rev 27) -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1531339132.3713707.1381958472044.javamail.r...@md01.wow.synacor.com
Bug#596700: The X server does not deallocate its vt upon shutdown. Restarting the X server results in the use of a higher-numbered vt.
Package: xorg Version: 1:7.5+6 I am running Debian Squeeze on the i386 architecture. The video card has an Nvidia RIVA TNT2 chipset. The nv driver (xserver-xorg-video-nv) is being used. The monitor is a CRT multi-sync monitor with DDC2/EDID support. My Desktop Environment is GNOME. Here's the scenario: (1) I boot the system. The X server starts on vt 7, running the gdm login interface daemon. I login on the X console using my non-superuser userid and password. This works fine. (2) I then logout of the desktop environment using System -> Logout from the GNOME action bar. Logout proceeds without incident, the X server shuts down, then restarts automatically. But when it restarts, it restarts on vt 8 instead of vt 7. This is not immediately apparent, but if I switch to vt 1 via Ctrl+Alt+F1, then attempt to switch back to the X server via Alt+F7, I see a black screen. If I use Alt+F8 instead, I see the gdm login screen. With the help of someone on the debian-user mailing list, plus some trial-and-error experimentation, I have come up with the following procedure which I use to get the X server back on vt 7 again, without a reboot: (a) When you see the gdm login screen again after logging out, switch to text console number 1 via Ctrl+Alt+F1. (b) login as root on vt 1. Attempt to deallocate vt 7 with deallocvt 7 This results in an error message: VT_DISALLOCATE: Device or resource busy (c) Issue the command killall console-kit-daemon (d) Once again issue the command deallocvt 7 This time it succeeds. (e) Restart gdm with /etc/init.d/gdm restart The X server shuts down and restarts, this time on vt 7. Note: for some installations, "/etc/init.d/gdm3 restart" is needed instead. Do not login yet! (f) Switch back to vt 1 via Ctrl+Alt+F1. (g) Issue the command deallocvt 8 to deallocate vt 8, which was used by the previous instance of the X server. This time it works. It is not necessary to kill the console-kit-daemon process this time. (i) Logout of the root session on vt 1. (j) Switch back to the X server via Alt+F7. (k) Login to the X server's desktop environment as usual. This is a cumbersome and convoluted work-around, but it works. The problem does not appear to be GNOME-related. Someone else on the debian-user mailing list requested help with these symptoms. He also was using the nv driver, but he was not using GNOME. He started the X server directly with "startx". I don't remember what window manager he was using, but he was not using a desktop environment. All he has to do is stop the X server, manually deallocate vt 7, and issue startx again. console-kit-daemon is apparently not used in his environment. It is apparently not specific to the nv driver either. I have seen these symptoms in the GNOME environment using the intel driver as well. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1319956917.71282.1284389205058.javamail.r...@md01.wow.synacor.com
Re: [RFC] removing xserver-xorg-video-nv from squeeze
On Tue, 13 Jul 2010 04:31:56 -0400 (EDT), Cyril Brulebois wrote: > > Care to share a reference to the bug you reported? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589452 -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1557363364.62018.1279405519348.javamail.r...@md01.wow.synacor.com
Bug#589452: nouveau driver doesn't work with interlaced video modes
*) Power Button: Applying InputClass "evdev keyboard catchall" (II) LoadModule: "evdev" (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so (II) Module evdev: vendor="X.Org Foundation" compiled for 1.7.6.901, module version = 2.3.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 7.0 (**) Power Button: always reports core events (**) Power Button: Device: "/dev/input/event2" (II) Power Button: Found keys (II) Power Button: Configuring as keyboard (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "pc104" (**) Option "xkb_layout" "us" (II) config/udev: Adding input device Power Button (/dev/input/event1) (**) Power Button: Applying InputClass "evdev keyboard catchall" (**) Power Button: always reports core events (**) Power Button: Device: "/dev/input/event1" (II) Power Button: Found keys (II) Power Button: Configuring as keyboard (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "pc104" (**) Option "xkb_layout" "us" (II) config/udev: Adding input device AT Translated Set 2 keyboard (/dev/input/event0) (**) AT Translated Set 2 keyboard: Applying InputClass "evdev keyboard catchall" (**) AT Translated Set 2 keyboard: always reports core events (**) AT Translated Set 2 keyboard: Device: "/dev/input/event0" (II) AT Translated Set 2 keyboard: Found keys (II) AT Translated Set 2 keyboard: Configuring as keyboard (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "pc104" (**) Option "xkb_layout" "us" (II) config/udev: Adding input device PS/2 Generic Mouse (/dev/input/event4) (**) PS/2 Generic Mouse: Applying InputClass "evdev pointer catchall" (**) PS/2 Generic Mouse: always reports core events (**) PS/2 Generic Mouse: Device: "/dev/input/event4" (II) PS/2 Generic Mouse: Found 3 mouse buttons (II) PS/2 Generic Mouse: Found relative axes (II) PS/2 Generic Mouse: Found x and y relative axes (II) PS/2 Generic Mouse: Configuring as mouse (**) PS/2 Generic Mouse: YAxisMapping: buttons 4 and 5 (**) PS/2 Generic Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (II) XINPUT: Adding extended input device "PS/2 Generic Mouse" (type: MOUSE) (II) PS/2 Generic Mouse: initialized for relative axes. (II) config/udev: Adding input device PS/2 Generic Mouse (/dev/input/mouse0) (II) No input driver/identifier specified (ignoring) (II) config/udev: Adding input device PC Speaker (/dev/input/event3) (II) No input driver/identifier specified (ignoring) (II) NOUVEAU(0): NVLeaveVT is called. -- Again, the symptom is a black screen. The X server stays running, but no output is visible. Switching to a text console works OK. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/338371527.61457.1279401503604.javamail.r...@md01.wow.synacor.com
Re: [RFC] removing xserver-xorg-video-nv from squeeze
On Tue, 13 Jul 2010 11:36:10 -0400 (EDT), Cyril Brulebois wrote: > Cyril Brulebois wrote: >> ... I didn't ask for an UMS-related bug reference. For some reason I was under the impression that KMS drivers were limited to modes which can be set by the video BIOS. I stand corrected. A bug report will be forth-coming. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2044848160.193276.1279129700306.javamail.r...@md01.wow.synacor.com
Re: [RFC] removing xserver-xorg-video-nv from squeeze
Cyril Brulebois wrote: > Care to share a reference to the bug you reported? Ben Hutchings wrote: > I assume you've filed a bug requesting support for custom modes, as > requested by the X maintainers? As Sven Joachim has pointed out, this would be an exercise in futility. Upstream deliberately removed support for UMS a while ago. From their point of view, this is not a bug, this is a "feature". And that's why I use the nv driver. Is KMS supposed to work with custom video modes? Is the nouveau driver supposed to work with custom video modes? If so, then perhaps it would be worthwhile to file a bug report. Otherwise, it's a waste of time. Stephen Powell wrote: > The intel driver supports both KMS and UMS. Cyril Brulebois wrote: > That's no longer correct. > http://ikibiki.org/blog/2010/07/04/We_need_you_redux/ Ben Hutchings wrote: > Not any more. As of xserver-xorg-video-intel 2:2.9.1-4, which is current in Squeeze, and for the i915G chipset, I can still pass modeset=0 to the i915 module and the X driver will still work. Are you saying that this is going to be taken away from me too? Oh joy! Ben Hutchings wrote: > Because UMS is a nasty hack that makes various features impossible, and > it is too much work to maintain both models. I'm beginning to see what I'm up against. I'm not trying to stand in the way of progress. I wish I could, however, stand in the way of regress. When you take away features that used to work and now don't anymore, that's not progress. Whether the actual mode setting takes place in kernel space or in user space is not my issue. I see the advantages of doing it in kernel space. The problem is two-fold, as I see it. (1) The kernel wants to set the mode once and leave it there, including when switching to a "text" console. It doesn't switch the card into a true hardware text mode. (2) It appears to me that the kernel (or video driver) may only support video modes that can be set by the video BIOS. Correct me if I'm wrong. (It wouldn't be the first time!) But no-one is listening. And if I stand in the way of regress, I'll get run over. (Sigh.) Of course, this is not a Debian-specific issue. Debian is just reacting to what is going on upstream. Keeping the nv driver is just delaying the inevitable, apparently. So I suppose I'll just have to throw out my monitor and use another one, even though there's nothing wrong with my existing monitor, because the video BIOS didn't anticipate my monitor's needs. "Progress". (If you're a hardware vendor.) Cyril Brulebois wrote: > Mraw, > KiBi. If this is supposed to mean something, perhaps you'll be kind enough to share it with me. A search of Internet slang did not yield any results that made sense to me in this context. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/765392348.156870.1279033877304.javamail.r...@md01.wow.synacor.com
Re: [RFC] removing xserver-xorg-video-nv from squeeze
On Mon, 12 Jul 2010 15:24:56 -0400 (EDT), Sven Joachim wrote: > On 2010-07-12 21:09 +0200, Stephen Powell wrote: >> If nouveau set KMS by default, as the intel driver does, but did not >> *require* KMS, I would agree. But the last time I checked, using the nouveau >> driver *forces* KMS. I don't like that. I still use, and prefer, hardware >> text mode virtual consoles (1-6). > > May I ask why? If the reason is that the default font is too small, you > can easily choose a bigger one, e.g. by "dpkg-reconfigure console-setup". > And speed shouldn't really be an issue either, unlike with vesafb. For a number of reasons. First, hardware text video modes seem to scroll faster in vi, less, etc. The frame buffer overhead is not as bad as it used to be, but hardware text modes still beat it. Second, I can't seem to get an 80-column virtual console with KMS. Yes, I can change the font size, but the traditional 80-column display doesn't seem to present itself. Maybe I just haven't tried hard enough. But frankly, I have little incentive to try very hard when I can just use hardware text modes with the nv driver. >> Because of that, I still use nv. That's >> the *only* reason that I still use nv. I take that back. There is a second reason. But it's related. nouveau ignores my custom video mode and insists on driving my CRT monitor at 1024x768 resolution (which is what I want) and at 60 Hz vertical refresh (which is *not* what I want). 60 Hz vertical refresh produces noticeable flicker and really irritates my eyes after only a few minutes. The only VESA standard video modes supported by my monitor for 1024x768 resolution are 1024x768 @ 60 Hz and 1024x768 @ 87 Hz Interlaced. The 87 Hz Interlaced mode produces far less perceived flicker and eye irritation than the 60 Hz mode, but I designed a custom video mode for 1024x768 @ 100 Hz Interlaced that is even better. (100 Hz is the maximum vertical refresh rate of the monitor). This mode is still within the video bandwidth of the monitor (maximum supported pixel clock rate). I'm very happy with it. But I can't get the nouveau driver to use my custom 100 Hz Interlaced mode, or even the VESA standard 87 Hz Interlaced mode. It insists on running the monitor at 60 Hz non-interlaced. And my eyes just won't take that for very long. At 100 Hz interlaced, I can look at the screen all day long with no eye strain. But at 60 Hz non-interlaced, my eyes are tired after 30 minutes or so. I assume that that is due to no support for UMS. >> There is no bug number here because >> I'm sure that upstream would consider this a feature and not a bug. In other >> words, they would consider operation of the driver with KMS off an >> enhancement >> request. > > Indeed you would be wasting your time, upstream deliberately removed all > UMS support from the nouveau X driver some months ago. That really annoys me. I was down on the nv driver because Nvidia decided not to add support for newer GPUs to it. But at least it supports UMS for older cards like mine. If you get rid of the nv driver, it looks like I will have to get another monitor or another video card, even though there is nothing wrong with either of them. The intel driver supports both KMS and UMS. I see no reason why the nouveau people should decide to RAM KMS down our throats, whether we want it or not. And with my present hardware, nv appears to be my only viable solution. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1009225337.144806.1278988270516.javamail.r...@md01.wow.synacor.com
Re: [RFC] removing xserver-xorg-video-nv from squeeze
On Mon, 12 Jul 2010 14:33:15 -0400 (EDT), Julien Cristau wrote: > > We're considering the removal of xserver-xorg-video-nv (the "free" X > driver for nvidia hardware) from sid and squeeze. I'm replying to both debian-x and debian-devel, but I am only subscribed to debian-devel. If you post only to debian-x, please CC me. If nouveau set KMS by default, as the intel driver does, but did not *require* KMS, I would agree. But the last time I checked, using the nouveau driver *forces* KMS. I don't like that. I still use, and prefer, hardware text mode virtual consoles (1-6). Because of that, I still use nv. That's the *only* reason that I still use nv. There is no bug number here because I'm sure that upstream would consider this a feature and not a bug. In other words, they would consider operation of the driver with KMS off an enhancement request. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2007940949.133394.1278961763880.javamail.r...@md01.wow.synacor.com
Bug#484516: X does not restore video mode properly when switching to a virtual console or terminating
Are you saying that the bug is fixed in lenny? It is my understanding that once a release goes stable, bugs in it are not normally fixed, except for security vulnerabilities. My goal was to report it now in the hopes that when lenny comes out it will be fixed in lenny. I am reluctant to upgrade to lenny at this point in time, because I don't want to give up security vulnerability support. But I will upgrade to lenny as soon as it goes stable. But I'd like the bug to be fixed by then, if it isn't fixed already. --- On Sat, 6/21/08, Brice Goglin <[EMAIL PROTECTED]> wrote: > From: Brice Goglin <[EMAIL PROTECTED]> > Subject: Re: Bug#484516: X does not restore video mode properly when > switching to a virtual console or terminating > To: "Stephen Powell" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Date: Saturday, June 21, 2008, 2:02 AM > Stephen Powell wrote: > > Package: xserver-xorg-core > > Version: 2:1.1.1-21etch4 > > > > X does not restore the video mode properly when > > switching to a virtual console or terminating. > > > > Any chance you upgrade your X to testing/Lenny? We are not > going to fix > Etch's X.org packages, they are way to old. > > Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#484516: X does not restore video mode properly when switching to a virtual console or terminating
Package: xserver-xorg-core Version: 2:1.1.1-21etch4 X does not restore the video mode properly when switching to a virtual console or terminating. To reproduce this problem, start the X server. Switch to a virtual console via Ctrl+Alt+Fn, where n = 1 to 6. Now change the text video mode using the SVGATextMode utility. For example, change from 80x25 (the default) to 80x33x9. Now resume the X server via Alt+F7. (I assume the default here, with the X server running on virtual console number 7.) Now switch to any virtual console via Ctrl+Alt+Fn or terminate X. The video mode is corrupted. When X transfers control to a virtual console via Ctrl+Alt+Fn, it restores the video registers as they existed at X startup, not as they existed when X was last resumed (via Alt+F7) from a virtual console. So the video registers no longer correspond to the logical screen size of the virtual console. The physical display is at 80x25 size (assuming that that is the size that existed at startup), but the logical screen size is still 33 lines long. So the command line is below the bottom of the physical screen. When X transfers control to a virtual console (via Ctrl+Alt+Fn), or when X terminates, it should restore the video registers as they existed when X was last resumed (via Alt+F7) from a virtual console. If X has never been resumed, only then should the registers as they existed at startup be restored. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
