Bug#349586: evdev locks my machine
On Wed, 2006-01-25 at 07:39 +0100, Harald Dunkel wrote: > Daniel Stone wrote: > > On Tue, Jan 24, 2006 at 07:40:09AM +0100, Harald Dunkel wrote: > > > Typos in the evdev entry lock up my machine, too, but > this is something I have influence upon. So we have 2 > separate bugs due to different severity. > > I would recommend to put the old evdev back. It could > distinguish the input ports by deeply looking, and it > did not die about typos. FWIW, I'm not sure the lockups are related to the evdev driver other than that they occur while the server aborts because the evdev driver failed to initialize. Thus Option "AllowMouseOpenFail" might serve as a workaround to avoid the lockups, but of course the mouse won't work until you adapt xorg.conf. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Bug#348054: xserver-xorg: [ati/radeon] Desktop window corrupted with ghost images
On Tue, 2006-01-24 at 21:26 +, Mark Brown wrote: > On Tue, Jan 24, 2006 at 12:11:22PM +0100, Michel Dänzer wrote: > > > * Option "RenderAccel" "off" > > This seemed to fix the ghosting problems but nothing else. Okay. Now, are you sure that EXA was enabled when you saw the ghosting with Option "AccelMethod" "EXA" as well? As noted in the other bug you mentioned, there's a known upstream bug in XAA (https://bugs.freedesktop.org/show_bug.cgi?id=4456) that causes a ghosting effect in the desktop rendered by Nautilus. If you really see the ghosting with EXA enabled, are the symptoms the same as with XAA? Otherwise, there might be a different bug in EXA causing similar symptoms. > > * Option "UseFBDev" (will only have an effect if radeonfb is > > active in the kernel) > > I don't have radeonfb loaded so I didn't try this. Would it be a lot of effort to load radeonfb and try it? > > Otherwise, did everything work fine with xserver-xorg 6.8.x? If so, can > > you please also provide a log file from that. > > The ghosting wasn't there but the other issues were. Do you need the > log given the above? Might still be interesting. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: Modular in Experimental
On Wed, Jan 25, 2006 at 12:20:29AM -0500, David Nusinow wrote: > On Mon, Jan 23, 2006 at 11:09:40PM -0500, David Nusinow wrote: > > Ok, status update: the common-packages are uploaded (xorg-common is in NEW) > > and tonight I uploaded the protocol headers, which are also sitting in NEW. > > Tomorrow I'm going to get started on the libs, which are sitting waiting > > for me to hand-hold their builds in a chroot. > > Ok, the libs, as you can see from all the messages, are all uploaded to > experimental. I'll be working on the drivers and such tomorrow. I've > decided to not unbundle the apps at present to avoid disrupting the archive > even more, so I may work on those tomorrow as well if I get time. Looks like you forgot to change the Maintainer field on libxpm, unless there's any particular reason that dak loves sending mail to [EMAIL PROTECTED] :) Cheers, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X Strike Force X.Org X11 SVN commit: r1114 - branches/modular/lib/libXcursor-X11R7.0-1.1.5.2/debian
On Mon, Jan 23, 2006 at 10:44:31PM -0500, X Strike Force SVN Repository Admin wrote: > Modified: branches/modular/lib/libXcursor-X11R7.0-1.1.5.2/debian/control > === > --- branches/modular/lib/libXcursor-X11R7.0-1.1.5.2/debian/control > 2006-01-24 03:09:30 UTC (rev 1113) > +++ branches/modular/lib/libXcursor-X11R7.0-1.1.5.2/debian/control > 2006-01-24 03:44:30 UTC (rev 1114) > @@ -3,7 +3,7 @@ > Priority: optional > Maintainer: Debian X Strike Force > Uploaders: Branden Robinson <[EMAIL PROTECTED]>, ISHIKAWA Mutsumi <[EMAIL > PROTECTED]>, Daniel Stone <[EMAIL PROTECTED]>, David Nusinow <[EMAIL > PROTECTED]> > -Build-Depends: cdbs (>= 0.4.12), debhelper (>= 4.0.0), x11proto-core-dev (>= > 7.0.1-1), libx11-dev (>= 1:0.9.2-1), libxrender-dev (>= 1:0.9.0-2), > libxfixes-dev (>= 1:3.0.0-4), pkg-config > +Build-Depends: debhelper (>= 4.0.0), x11proto-core-dev (>= > 6.2.1+cvs.20050722-1), libx11-dev (>= 1:6.2.1+cvs.20050722-1), libxrender-dev > (>= 1:0.9.0-1), libxfixes-dev (>= 1:3.0.0-2), pkg-config > Standards-Version: 3.6.1 > > Package: libxcursor1 You can take me out of the uploaders field here. I'd imagine Ishikawa wouldn't have much use for it these days, either. libxcursor should probably be shadowing most of the XSF packages in this regard, I'd imagine. Cheers, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
evdev driver in xorg-x11 (6.9.0.dfsg.1-3)
hi! i have here a system witch runs two Xservers, has two heads with two displays, two keyboards and two mice. I used to use the evdev driver and identified my devices like this: Option "Dev Name" "ELECOM ELECOM imagesensor mouse with wheel" note the cool name whith which i could identify it easily by its internal name. Alternatively i could give the device path like this: # Option "Dev Phys" "usb-:00:02.3-1.1/input0" now the new driver requires a device file. how do you recommend to do that, so that the mice and keyboards are told apart reliably? I am curious: why wasn't our (superior?) driver integrated upstream instead? it seemed more feature full and usefull. signature.asc Description: Digital signature
Bug#126519: Your requested Information : Y23819-45696
Hey [EMAIL PROTECTED], We spoke a few days ago and I'd like to confirm everything now. Please go over the information below and let me know if you have any questions. queenla.com/am We are accepting your form. Your status has been accepted. We need to confirm your details one more time. Just check the URL above and fill out our last form. See you later, [EMAIL PROTECTED] Titor Mary -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#24192: Refinance Info : I719241-04105
Good day, We spoke a few days ago and I'd like to confirm everything now. Please go over the information below and let me know if you have any questions. queenla.com/am We are accepting your form. Your status has been accepted. We need to confirm your details one more time. Just check the URL above and fill out our last form. See you later, [EMAIL PROTECTED] Cary Kinsella -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Modular in Experimental
El martes, 24 de enero de 2006 05:09, David Nusinow escribió: > Ok, status update: the common-packages are uploaded (xorg-common is in NEW) > and tonight I uploaded the protocol headers, which are also sitting in NEW. > Tomorrow I'm going to get started on the libs, which are sitting waiting > for me to hand-hold their builds in a chroot. Hello, David. I have a question, are you forward-porting all the changes we are doing to 6.9 to 7.0? Best regards, Ender. -- Network engineer Debian Developer pgpdiialhO6mX.pgp Description: PGP signature
Re: xterm debian package
El lunes, 23 de enero de 2006 19:39, Folkert van Heusden escribió: > Hi, > > Could you please consider enabling the functionality in the xterm debian > package for more then 8 colors? E.g. 256? And maybe you can enable the > functionality that programs can change the r, g and b values of each > color? According to ncurses this should be possible somehow but xterm > doesn't support it. Hello, Folkert. Excuse me, but what do you base your statement on? From xterm package changelog: xterm (204-0pre1) experimental; urgency=low [...] * Added --enable-256-color to configure (closes: #305540). [...] Maybe you have testing or stable? Best regards, Ender. -- Network engineer Debian Developer pgpmUqXx4h1Ir.pgp Description: PGP signature
Re: xterm debian package
> > Could you please consider enabling the functionality in the xterm debian > > package for more then 8 colors? E.g. 256? And maybe you can enable the > > functionality that programs can change the r, g and b values of each > > color? According to ncurses this should be possible somehow but xterm > > doesn't support it. > Hello, Folkert. Excuse me, but what do you base your statement on? > From xterm package changelog: > xterm (204-0pre1) experimental; urgency=low > [...] > * Added --enable-256-color to configure (closes: #305540). > [...] > Maybe you have testing or stable? Ah yes, you're right; using testing here. Sorry for the inconvenience and thanks for replying! Folkert van Heusden -- www.vanheusden.com/recoverdm/ - got an unreadable cd with scratches? recoverdm might help you recovering data Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com signature.asc Description: Digital signature
Bug#349908: xserver-xorg: document what 'DDC' stands for
Package: xserver-xorg Version: 6.8.2.dfsg.1-11 Severity: wishlist Tags: upstream It doesn't seem to be documented anywhere in the package what the acronym "DDC" stands for. Had to do $ apropos DDC to find the answer in /usr/share/man/man1/get-edid.1.gz Anyway, make sure the user can find out what each possible 'Section "Module"' item is all about. P.S. $ man xorg.conf Clocks clock ... specifies the pixel that are on your graphics board. "the pixel that are on your graphics board"?? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348054: xserver-xorg: [ati/radeon] Desktop window corrupted with ghost images
On Wed, Jan 25, 2006 at 09:53:37AM +0100, Michel Dänzer wrote: > Okay. Now, are you sure that EXA was enabled when you saw the ghosting > with Option "AccelMethod" "EXA" as well? As noted in the other bug you > mentioned, there's a known upstream bug in XAA > (https://bugs.freedesktop.org/show_bug.cgi?id=4456) that causes a > ghosting effect in the desktop rendered by Nautilus. > If you really see the ghosting with EXA enabled, are the symptoms the > same as with XAA? Otherwise, there might be a different bug in EXA > causing similar symptoms. How could I confirm if it was on? I've tried toggling EXA off in the configuration file and I now get ghosting again, even with RenderAccel on, so it does look like two bugs. With EXA the ghosts are greyscale patterns whereas with XAA they mostly seem to be derived from things to the top left of the screen. The areas where ghosting appears (IYSWIM) do seem relatively similar, though obviously I can't do a side by side comparison. > > I don't have radeonfb loaded so I didn't try this. > Would it be a lot of effort to load radeonfb and try it? Probably not but I don't have much time tonight: I will try to find time over the next couple of days to run through that and also try the things you suggested before with EXA disabled (changing down to 16 bit doesn't help XAA - that was my configuration when I first saw trouble). -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#349924: Wrong Permissions on tty
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: xterm Version: 208-3.1 Severity: normal Tags: sid The newest xterm set the wrong permissions on tty: ikki:~> ls -l `tty` crw--w--w- 1 klaus ethgen 136, 9 2006-01-25 22:50 /dev/pts/9 this should be: crw--w--w- 1 klaus tty136, 9 2006-01-25 22:50 /dev/pts/9 /etc/default/devpts: # GID of the `tty' group TTYGRP=5 ... (gid 5 is group tty This wrong permissions are problematic with other tools. - -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (800, 'unstable'), (700, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.32 Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) (ignored: LC_ALL set to de_DE) Versions of packages xterm depends on: ii libc6 2.3.5-12 GNU C Library: Shared libraries an ii libfontconfig12.3.2-1.1 generic font configuration library ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib ii libice6 6.9.0.dfsg.1-4 Inter-Client Exchange library ii libncurses5 5.5-1 Shared libraries for terminal hand ii libsm66.9.0.dfsg.1-4 X Window System Session Management ii libx11-6 6.9.0.dfsg.1-4 X Window System protocol client li ii libxaw8 6.9.0.dfsg.1-4 X Athena widget set library ii libxext6 6.9.0.dfsg.1-4 X Window System miscellaneous exte ii libxft2 2.1.8.2-1 FreeType-based font drawing librar ii libxmu6 6.9.0.dfsg.1-4 X Window System miscellaneous util ii libxrender1 1:0.9.0.2-1X Rendering Extension client libra ii libxt66.9.0.dfsg.1-4 X Toolkit Intrinsics ii xlibs-data6.9.0.dfsg.1-4 X Window System client data ii zlib1g1:1.2.3-9 compression library - runtime Versions of packages xterm recommends: ii xutils6.9.0.dfsg.1-4 X Window System utility programs - -- no debconf information - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]> Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iQEVAwUBQ9fzc5+OKpjRpO3lAQIGzgf7BW163B/vjzX3Hl8mQfEtb/b7XqtsIeqw YldvRKlJMxdYdwS8VcrDcVTN4HMldkON2SuSmWe9xZLWPwe3bw1QxYc88MUXlL+a BqJ+KRMB5oegYKCdqkGB196fgePgx+r8pVFu7sDfDpH3fvs3wK2j7FnEIF0W/xQ/ +WW70Qdg2WiwiJ1/qrscbqa9pH6V9uZ80KRozbmoXoMmKO3N69or4MYh2rDniosy wTprqSPwULiWUr3Cn1gZRKBy7QlgVgWFWSA0RB+aV1N/39ARjf9uU9gs/lyw//nm UALtfVCK413im6NWmdPMlmj6J4JI+k5qEDGdSwquotEBrSS503mV+A== =9Xq8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: evdev driver in xorg-x11 (6.9.0.dfsg.1-3)
On Wed, Jan 25, 2006 at 05:03:52PM +0100, Andreas Schuldei wrote: > i have here a system witch runs two Xservers, has two heads with > two displays, two keyboards and two mice. > > I used to use the evdev driver and identified my devices like > this: > Option "Dev Name" "ELECOM ELECOM image sensor mouse > with wheel" > > note the cool name whith which i could identify it easily by its > internal name. Alternatively i could give the device path like > this: > > # Option "Dev Phys" "usb-:00:02.3-1.1/input0" > > now the new driver requires a device file. how do you recommend > to do that, so that the mice and keyboards are told apart > reliably? Use a udev rule. > I am curious: why wasn't our (superior?) driver integrated > upstream instead? it seemed more feature full and usefull. For various reasons, it was felt that evdev warranted its own driver, instead of being hacked into the kbd/mouse drivers which were already bloated with random code. The normal evdev is getting there; there are patches for XKB support, f.e. Cheers, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Modular in Experimental
On Wed, Jan 25, 2006 at 08:39:33PM +1100, Daniel Stone wrote: > On Wed, Jan 25, 2006 at 12:20:29AM -0500, David Nusinow wrote: > > On Mon, Jan 23, 2006 at 11:09:40PM -0500, David Nusinow wrote: > > > Ok, status update: the common-packages are uploaded (xorg-common is in > > > NEW) > > > and tonight I uploaded the protocol headers, which are also sitting in > > > NEW. > > > Tomorrow I'm going to get started on the libs, which are sitting waiting > > > for me to hand-hold their builds in a chroot. > > > > Ok, the libs, as you can see from all the messages, are all uploaded to > > experimental. I'll be working on the drivers and such tomorrow. I've > > decided to not unbundle the apps at present to avoid disrupting the archive > > even more, so I may work on those tomorrow as well if I get time. > > Looks like you forgot to change the Maintainer field on libxpm, unless > there's any particular reason that dak loves sending mail to [EMAIL > PROTECTED] :) Argh, thanks for catching that one :-) I need to just use sed the next time. I've got to deal with all the REJECTED notices too, but we'll see the libs all sitting nicely in NEW soon enough... - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Modular in Experimental
On Wed, Jan 25, 2006 at 08:34:39PM +0100, David Martínez Moreno wrote: > El martes, 24 de enero de 2006 05:09, David Nusinow escribió: > > Ok, status update: the common-packages are uploaded (xorg-common is in NEW) > > and tonight I uploaded the protocol headers, which are also sitting in NEW. > > Tomorrow I'm going to get started on the libs, which are sitting waiting > > for me to hand-hold their builds in a chroot. > > Hello, David. I have a question, are you forward-porting all the > changes we > are doing to 6.9 to 7.0? Yes, see the TODO in the modular branch. Please don't do any really serious work on 6.9 though unless you're willing to take responsibility for being sure it gets ported to 7.0 also. Since I'm the only one who's actively hacking on 7.0 right now, I'd much prefer to get a version of 7.0 in to unstable for testing ASAP than worry about forward porting a zillion fixes that were backported from upstream to our 6.9 tree. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349932: xserver-xorg: Xorg server crash: symbol lookup error: MGAGetBOARDHANDLESize
Package: xserver-xorg Version: 6.9.0.dfsg.1-4 Severity: important I have dist-upgraded my 'unstable' system today. Since then, the X server crashes. It has been working fine for years. The output on the console is as follows: rillanon:/# X X Window System Version 6.9.0 (Debian 6.9.0.dfsg.1-4 20060114230205 David Nusinow <[EMAIL PROTECTED]>) Release Date: 21 December 2005 X Protocol Version 11, Revision 0, Release 6.9 Build Operating System: Linux 2.6.15-1-686 i686 [ELF] Current Operating System: Linux rillanon 2.6.11-1-686 #1 Mon Jun 20 22:00:38 MDT 2005 i686 Build Date: 14 January 2006 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present OS Kernel: Linux version 2.6.11-1-686 ([EMAIL PROTECTED]) (gcc version 3.3.6 (Debian 1:3.3.6-6)) #1 Mon Jun 20 22:00:38 MDT 2005 F Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jan 25 23:42:39 2006 (==) Using config file: "/etc/X11/xorg.conf" X: symbol lookup error: /usr/X11R6/lib/modules/drivers/mga_drv.so: undefined symbol: MGAGetBOARDHANDLESize -- Package-specific info: Contents of /var/lib/xfree86/X.roster: xserver-xfree86 xserver-xorg /etc/X11/X target unchanged from checksum in /var/lib/xfree86/X.md5sum. X server symlink status: lrwxrwxrwx 1 root root 17 2005-11-05 22:22 /etc/X11/X -> /usr/bin/X11/Xorg -rwxr-xr-x 1 root root 1878044 2006-01-15 02:40 /usr/bin/X11/Xorg Contents of /var/lib/xfree86/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: :01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP (rev 01) /etc/X11/xorg.conf does not match checksum in /var/lib/xfree86/xorg.conf.md5sum. Xorg X server configuration file status: -rw-r--r-- 1 root root 5523 2006-01-25 22:55 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # XF86Config-4 (XFree86 X server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type "man XF86Config-4" at the shell prompt.) # # This file is automatically updated on xserver-xfree86 package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xfree86 # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/XF86Config-4 /etc/X11/XF86Config-4.custom # md5sum /etc/X11/XF86Config-4 > /var/lib/xfree86/XF86Config-4.md5sum # dpkg-reconfigure xserver-xfree86 #Section "ServerLayout" # Identifier "Default Layout" # Screen "Default Screen" # InputDevice "Generic Keyboard" # InputDevice "Configured Mouse" #EndSection #Section "Monitor" # Identifier "Display Merged" # HorizSync30.0 - 57.0 # VertRefresh 43.0 - 72.0 #EndSection #Section "Screen" # Identifier "Display Merged" # Device "MATROX CARD 1" # Monitor"Display Merged" # DefaultDepth 16 # Option "Monitor2Position" "RightOf" # Option "MetaModes" "1024x768-1024x768 800x600-800x600 640x480-640x480 1024x768 800x600 640x480 " # Option "Monitor2HSync" "30.0-57.0 " # Option "Monitor2VRefresh" "43.0-72.0 " # Option "MergedFB" # SubSection "Display" # #Virtual 2048 768 # Virtual 2560 1024 # Depth 16 # Modes"1280x1024" "1024x768" "800x600" "640x480" # EndSubSection #EndSection # Section "ServerLayout" # Screen "Default Screen" RightOf "Secondary Screen" Identifier "Matrox PowerDesk configured." Screen "Display 1" LeftOf "Display 2" Screen "Display 2" 0 0 InputDevice"Generic Keyboard" InputDevice"Configured Mouse" Option "Xinerama" "off" # Screen "Secondary Screen" EndSection Section "Files" # local font server # if the local font server has problems, we can fall back on these FontPath "unix/:7100" FontPath "/usr/lib/X11/fonts/Type1" FontPath "/usr/lib/X11/fonts/CID" FontPath "/usr/lib/X11/fonts/Speedo" FontPath "/usr/lib/X11/fonts/misc" FontPath "/usr/lib/X11/fonts/cyrillic" FontPath "/usr/lib/X11/fonts/100dpi" FontPath "/usr/lib/X11/fonts/75dpi" EndSection Section "Module" #Load "vbe" # Option "omit xfree86-dga" # EndSubSection # Load"int10" Load "ddc" # Load"record" Load "dbe" Load "v4l" Load "extmod" # SubSection "extmod"
Bug#349924: Wrong Permissions on tty
On Wed, Jan 25, 2006 at 11:20:15PM +0100, Klaus Ethgen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Package: xterm > Version: 208-3.1 > Severity: normal > Tags: sid > > The newest xterm set the wrong permissions on tty: > ikki:~> ls -l `tty` > crw--w--w- 1 klaus ethgen 136, 9 2006-01-25 22:50 /dev/pts/9 > > this should be: > crw--w--w- 1 klaus tty136, 9 2006-01-25 22:50 /dev/pts/9 I believe this is the same problem as #349142. I think it's a case where the build environment lacks a "tty" in its /etc/group file, and have added an option to the configure script to allow the packager to force it to work around this case (will be in #209). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpaQr6z7SzT8.pgp Description: PGP signature
Processed: setting forwarded
Processing commands for [EMAIL PROTECTED]: > package xserver-xorg Ignoring bugs not assigned to: xserver-xorg > forwarded 348730 https://bugs.freedesktop.org/show_bug.cgi?id=5699 Bug#348730: xserver-xorg/glint sometimes freezes Noted your statement that Bug has been forwarded to https://bugs.freedesktop.org/show_bug.cgi?id=5699. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Slow AA and RGB text rendering
I'm aware that Render acceleration of anti-aliased text has been a persistent problem in upstream xorg for quite awhile now, but I'm wondering if anyone knows whether there is an end in sight. The current situation is one of severe breakage and seems to be getting worse, not better. Here are some data points for perspective... On the following machine: Athlon64 3000 Nvidia GeForce 6600GT Kernel 2.6.14, Xorg 6.9.0.dfsg.1-3 (Render enabled and verified working, Composite disabled, GLX working) I'm getting only 22 kchar/s using: x11perf -rgb10text Even software rendering should not be THIS slow considering that... ..For comparison, I dug out a retired P2-266 laptop with a PCI S3 video chipset. It hasn't been updated for years. (Kernel 2.6.1, XFree86 4.2.1-16) The same benchmark reported about 17 kchar/s. [Sidenote: for some reason x11perf -aa10text is not working in 6.9.0.. it still does RGB and reports the same result. Otherwise, I would have reported this as well. Nevertheless, my guess is that the result would be the same, judging by perceptible text redraw speed in applications with AA vs RGB mode.] Also, for reference, my prior Radeon 8500 card gave similar poor results. Before Xorg 6.9.0, I got around 45-50 kchar/s in either AA or RGB mode using x11perf -aa10text or -rgb10text respectively. While this sounds much faster, it is nowhere near what it should be and still results in visibly sluggish text redraw. I used to get around 250-300 kchar/s with AA text in some older XFree86 releases (and one CVS checkout of pre-6.8.2 Xorg!) with varied Radeon hardware. (RGB was still slow, around 50 kchar/s) If anyone has patches they'd like help testing, I'm certainly willing. :) Performance this bad is a show-stopper for desktop Linux IMO. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
