Bug#268731: My problem
Hi There, Is there any solution about my report. I checked the bugreport page of debian. It seems no any progress about my problem
Re: new nv driver that should fix Xv extensions: please test!
On Mon, Sep 20, 2004 at 02:24:00PM +0200, Fabio Massimo Di Nitto wrote: Hi everybody, thanks a lot for all the tests you have been done so far. I uploaded again a new nv driver that should fix the Xv extension here: http://people.no-name-yet.com/~fabbione/nv/i386/ Do you also have a ppc binary?
Re: new nv driver that should fix Xv extensions: please test!
On Mon, 20 Sep 2004, Christoph Hellwig wrote: On Mon, Sep 20, 2004 at 02:24:00PM +0200, Fabio Massimo Di Nitto wrote: Hi everybody, thanks a lot for all the tests you have been done so far. I uploaded again a new nv driver that should fix the Xv extension here: http://people.no-name-yet.com/~fabbione/nv/i386/ Do you also have a ppc binary? Not yet.. I hope to have them in a few hours. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: new nv driver that should fix Xv extensions: please test!
They are up now: http://people.no-name-yet.com/~fabbione/nv/powerpc/ sorry.. the 2 files are bigger than the others because they haven't be stripped from the debugging symbols, but they will work as the normal one. This one works fine for me.
Re: Still having lots of trouble with Alt/Meta keys
Daniel Jacobowitz [EMAIL PROTECTED] writes: All I want is for my Windows keys to send Meta, and xterm to treat that like Escape. This requires XTerm*metaSendsEscape: true. [For some reason, I have to start an xterm, run xrdb in it, and start a new xterm for this to take effect. I can't run it from a VT with $DISPLAY set; it just switches to the X server instead of merging resources. Huh.] Try running xrdb with the -retain option: -retain This option indicates that the server should be instructed not to reset if xrdb is the first client. This never be necessary (sic.) under normal conditions, since xdm and xinit always act as the first client. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Still having lots of trouble with Alt/Meta keys
On Mon, Sep 20, 2004 at 01:46:53PM -0400, Aaron M. Ucko wrote: Daniel Jacobowitz [EMAIL PROTECTED] writes: All I want is for my Windows keys to send Meta, and xterm to treat that like Escape. This requires XTerm*metaSendsEscape: true. [For some reason, I have to start an xterm, run xrdb in it, and start a new xterm for this to take effect. I can't run it from a VT with $DISPLAY set; it just switches to the X server instead of merging resources. Huh.] Try running xrdb with the -retain option: -retain This option indicates that the server should be instructed not to reset if xrdb is the first client. This never be necessary (sic.) under normal conditions, since xdm and xinit always act as the first client. O Thanks, I see why it happened now. -- Daniel Jacobowitz
Re: Bug#263891: XFree86, X server crashed
On Wed, Sep 01, 2004 at 03:12:24AM -0700, Daniel Stone wrote: On Wed, Sep 01, 2004 at 04:48:58AM -0500, Branden Robinson wrote: reassign 263891 xserver-xfree86 retitle 263891 xserver-xfree86: SIGILL on Dell Dimension XPS Pro 200n tag 263891 + moreinfo upstream thanks [...] Therefore, I strongly urge you to give reportbug a try as your primary bug reporting tool for the Debian System, and try filing your report again. Won't following this advice cause the reporter to get another form letter telling them off for filing duplicate bugs? No, because I accidentally sent the wrong form letter in the first place, and I won't punish the submitter for my own error. -- G. Branden Robinson| There's something wrong if you're Debian GNU/Linux | always right. [EMAIL PROTECTED] | -- Glasow's Law http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Processed: Re: Bug#264557: xlibs-data: No composition sequences in japanese locale
Processing commands for [EMAIL PROTECTED]: tag 264557 + moreinfo upstream Bug#264557: xlibs-data: No composition sequences in japanese locale There were no tags set. Tags added: moreinfo, upstream thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Processed: Re: Bug#265829: xdm doesn't start at boot, but runs ok with /etc/init.d/xdm
Processing commands for [EMAIL PROTECTED]: reassign 265829 xserver-xfree86 Bug#265829: xdm doesn't start at boot, but runs ok with /etc/init.d/xdm Bug reassigned from package `xdm' to `xserver-xfree86'. retitle 265829 xserver-xfree86: [ati/r128] server sometimes fails to start with 'Memory manager initialization to (0,0) (288,0) failed' on Rage Mobility M3 AGP 2x rev 2 Bug#265829: xdm doesn't start at boot, but runs ok with /etc/init.d/xdm Changed Bug title. severity 265829 important Bug#265829: xserver-xfree86: [ati/r128] server sometimes fails to start with 'Memory manager initialization to (0,0) (288,0) failed' on Rage Mobility M3 AGP 2x rev 2 Severity set to `important'. tag 265829 + upstream help Bug#265829: xserver-xfree86: [ati/r128] server sometimes fails to start with 'Memory manager initialization to (0,0) (288,0) failed' on Rage Mobility M3 AGP 2x rev 2 Tags were: moreinfo Tags added: upstream, help thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Processed: Re: Bug#266692: xserver-xfree86: X get sig 11 when loading pcidata module on 3D Rage Pro 215GP (rev 5c) (on Sun Ultra5) with kernels 2.6.7
Processing commands for [EMAIL PROTECTED]: retitle 266692 xserver-xfree86: [atimisc] SEGV when loading pcidata module on 3D Rage Pro 215GP (rev 5c) on Sun Ultra5 and Linux 2.6.7 Bug#266692: xserver-xfree86: X get sig 11 when loading pcidata module on 3D Rage Pro 215GP (rev 5c) (on Sun Ultra5) with kernels 2.6.7 Changed Bug title. tag 266692 + moreinfo upstream Bug#266692: xserver-xfree86: [atimisc] SEGV when loading pcidata module on 3D Rage Pro 215GP (rev 5c) on Sun Ultra5 and Linux 2.6.7 There were no tags set. Tags added: moreinfo, upstream thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Processed: Re: Bug#266274: xserver-xfree86: Backslash key doesn't work when using evdev keyboard driver.
Processing commands for [EMAIL PROTECTED]: retitle 266274 xserver-xfree86: [kbd] backslash key doesn't work with xfree86/pc105/gb XKB configuration Bug#266274: xserver-xfree86: Backslash key doesn't work when using evdev keyboard driver. Changed Bug title. tag 266274 + upstream patch Bug#266274: xserver-xfree86: [kbd] backslash key doesn't work with xfree86/pc105/gb XKB configuration Tags were: upstream moreinfo Tags added: upstream, patch thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Processed: Re: Bug#267231: xlibs-data: Plane 1 in Compose file damaged
Processing commands for [EMAIL PROTECTED]: retitle 267231 xlibs-data: [en_US.UTF-8/Compose] Unicode Plane 1 characters damaged Bug#267231: xlibs-data: Plane 1 in Compose file damaged Changed Bug title. tag 267231 + upstream Bug#267231: xlibs-data: [en_US.UTF-8/Compose] Unicode Plane 1 characters damaged There were no tags set. Tags added: upstream thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
X Strike Force XFree86 SVN commit: r1832 - in trunk/debian: . local
Author: branden Date: 2004-09-20 15:04:07 -0500 (Mon, 20 Sep 2004) New Revision: 1832 Modified: trunk/debian/CHANGESETS trunk/debian/TODO trunk/debian/local/FAQ.xhtml Log: Tidy up some language in the new XKB layout FAQ entry and identify areas where further clarification is needed. Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-09-20 12:11:14 UTC (rev 1831) +++ trunk/debian/CHANGESETS 2004-09-20 20:04:07 UTC (rev 1832) @@ -51,6 +51,6 @@ Add FAQ entry: My keyboard configuration worked with XFree86 4.2; why is it messed up now? (Closes: #259740) -1823 +1823, 1832 vim:set ai et sts=4 sw=4 tw=80: Modified: trunk/debian/TODO === --- trunk/debian/TODO 2004-09-20 12:11:14 UTC (rev 1831) +++ trunk/debian/TODO 2004-09-20 20:04:07 UTC (rev 1832) @@ -17,6 +17,7 @@ 4.3.0.dfsg.1-8 -- +* Address BR's confusion in the new xkbnewlayout FAQ question. * Fix for the nv driver breakage, consider backporting the driver from x.org. See: #269025, #268759, #271235, #270228, #271071 Modified: trunk/debian/local/FAQ.xhtml === --- trunk/debian/local/FAQ.xhtml2004-09-20 12:11:14 UTC (rev 1831) +++ trunk/debian/local/FAQ.xhtml2004-09-20 20:04:07 UTC (rev 1832) @@ -150,7 +150,7 @@ my X session exiting abnormally?/a/li lia href=#radeondualheadI'm having trouble getting dual-head support to work on my ATI Radeon card. Can you help?/a/li -lia href=#xkbnewlayoutMy keyboard configuration worked with XFree86 4.2, +lia href=#xkbnewlayoutMy keyboard configuration worked with XFree86 4.2; why is it messed up now?/a/li /ul h2a href=#acknowledgementsAcknowledgements/a/h2 @@ -2675,45 +2675,57 @@ class=otherMonitorLayout/code line, but I can't think of a physical mechanism for this actually happening./p -h3a id=xkbnewlayoutMy keyboard configuration worked with XFree86 4.2, +h3a id=xkbnewlayoutMy keyboard configuration worked with XFree86 4.2; why is it messed up now?/a/h3 -pIn releases previous to XFree86 4.3, combining several keymaps was -difficult because keymaps had to be defined for each position. For instance -codeus/code keymap was defined on first, second and third position, -and this should have been done for all keymaps./p +pemThanks to Denis Barbier for contributing this entry./em/p -pKeymap layouts have been revisited in XFree86 4.3, and new definitions -can now be used in whatever order so that codeus,ru/code and -coderu,us/code use the same definitions. New definitions have been put -into code class=filespec/etc/X11/xkb/symbols/pc//code and old ones are -still available at the same place, ie. under the -code class=filespec/etc/X11/xkb/symbols//code directory,/p +pem[TODO: This entry needs to be more careful with keymap versus layout +terminology. Also, I don't understand the first paragraph or the first sentence +of the second paragraph. Do the mentioned positions have to do with shift +levels? Also, what relationship do shift levels have with groups? mdash; +BR]/em/p -pSome keymaps have not been converted to the new layout for any reason, -and thus can not be combined with other keymaps. They are listed into -code class=filespec/etc/X11/xkb/rules/xfree86/code. If you have -trouble combining keymaps, check that you do not try to load a keymap -listed there./p +pIn releases previous to XFree86 4.3, combining several layouts was difficult +because keymaps had to be defined for each position. For example, +codeus/code keymap was defined on first, second and third position, and this +should have been done for all keymaps./p -pModifiers have also been affected by these major changes to make this -system more modular. A consequence is that emfake keys/em have been -introduced in XKB data files for codeAlt/code, codeMeta/code, -codeSuper/code and codeHyper/code modifiers. -By default, codemod1/code and codemod4code use these fake keys -instead of real ones. XKB-aware applications can handle those fake -keys, but several applications get confused and do no more recognize -your keys as modifiers. Until these applications are fixed, you can -bind keys explicitly with codealtwin/code options, e.g. -kbdOption altwin:super_win/kbd binds your logo keys to -codeSuper/code modifiers./p +pKeymap layouts have been revisited in XFree86 4.3, and new definitions can +now be used in arbitrary order so that codeus,ru/code and coderu,us/code +use the same codesymbols/code files. The new definitions have been placed +in code class=filespec/etc/X11/xkb/symbols/pc//code while the old ones are +still available in their traditional location; that is, directly within the +code class=filespec/etc/X11/xkb/symbols//code directory./p +pSome symbols files have not been converted to the new layout, and thus can +not be combined
Bug#267062: xlibs: [xkb] wrong Compose file for pl_PL.UTF-8?
On Mon, Aug 30, 2004 at 12:42:18AM +0200, Shot wrote: ...uxterm, you say. This gets interesting - uxterm works for me according to the compose maps, that is it seems to be using en_US.UTF-8/Compose; I *can* get per mille, I *can't* get aogonek. Does this mean there's something broken in GTK/GNOME? Mozilla, Galeon, gnome-terminal: all broken. xterm, uxterm, OpenOffice.org Writer: all working. Jeff Licquia told me this has to do with the GNOME input method you have configured. Jeff, can you mail [EMAIL PROTECTED] with a little more elaboration? -- G. Branden Robinson| Debian GNU/Linux | // // // / / [EMAIL PROTECTED] | EI 'AANIIGOO 'AHOOT'E http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#266692: xserver-xfree86: X get sig 11 when loading pcidata module on 3D Rage Pro 215GP (rev 5c) (on Sun Ultra5) with kernels 2.6.7
retitle 266692 xserver-xfree86: [atimisc] SEGV when loading pcidata module on 3D Rage Pro 215GP (rev 5c) on Sun Ultra5 and Linux 2.6.7 tag 266692 + moreinfo upstream thanks On Wed, Aug 18, 2004 at 08:30:49PM +0200, Torbjörn Olander wrote: Package: xserver-xfree86 Version: 4.3.0.dfsg.1-6 Severity: important ig 11 when loading pcidata module on 3D Rage Pro 215GP (rev 5c) (on Sun Ultra5) with kenels 2.6.7 [The following is a form letter.] Dear bug submitter, Since the XFree86 X server is a large and complex piece of software, some more information is required of you before this bug can be handled. Please run the following commands from a shell prompt to gather and deliver this information to us: $ /usr/share/bug/xserver-xfree86 /tmp/output 31 $ mailx -s Re: Bug#266692 [EMAIL PROTECTED] /tmp/output If you do not have a mailx command on your system, you can get it by installing the mailx Debian package; for example, with the aptitude install mailx or apt-get install mailx commands as root. Alternatively, you can also use a mail command that is compatible with mailx's command-line syntax, such as mutt. One very good way to file bugs with the Debian Bug Tracking System is to use the reportbug package and command of the same name. The reportbug program does a lot of automatic information-gathering that helps package maintainers to understand your system configuration, and also ensures that your message to the Debian Bug Tracking System is well-formed so that it is processed correctly by the automated tools that manage the reports. (If you've ever gotten a bounce message from the Debian Bug Tracking System that tells you your message couldn't be processed, you might appreciate this latter feature.) Therefore, I strongly urge you to give reportbug a try as your primary bug reporting tool for the Debian System in the future. If you *did* use reportbug to file your report, then you're receiving this message because the information we expected to see was not present. If you deliberately deleted this information from the report, please don't do that in the future, even if it seems like it makes the mail too large. 50 kB (kilobytes) of configuration and log data is typical. Only if the included information greatly exceeds this amount (more than 100 kB) should you consider omitting it; instead, put it up on the World Wide Web somewhere and provide URLs to it in your report, or in subsequent followup by mailing [EMAIL PROTECTED]. Thank you! -- G. Branden Robinson| Q: How does a Unix guru have sex? Debian GNU/Linux | A: unzip;strip;touch;finger;mount; [EMAIL PROTECTED] |fsck;more;yes;fsck;fsck;fsck; http://people.debian.org/~branden/ |umount;sleep signature.asc Description: Digital signature
Bug#266274: xserver-xfree86: Backslash key doesn't work when using evdev keyboard driver.
retitle 266274 xserver-xfree86: [kbd] backslash key doesn't work with xfree86/pc105/gb XKB configuration tag 266274 + upstream patch thanks On Sun, Aug 22, 2004 at 11:47:15PM +0100, Timothy Baldwin wrote: Does the key work with the keyboard driver? Your configuration otherwise looks okay (xfree86/pc105/gb). Yes, it does. Definitely a kbd-driver-specific problem. Also, can you tell me what this Dev Phys option is? It's not documented in kbd(4x). (I have to admit I don't know much about the new kbd driver, nor evdev, yet.) It specifies which keyboard the driver should use. See http://people.debian.org/~warp/evdev/readme and http://tldp.org/HOWTO/XFree-Local-multi-user-HOWTO/tweak_input_devs-xev1.html for documentation, the patches are included in the package. I have managed fix this myself, see attached patch. Thanks! Do you know what the 102ND code is supposed to do? -- G. Branden Robinson|Imagination was given man to Debian GNU/Linux |compensate for what he is not, and [EMAIL PROTECTED] |a sense of humor to console him for http://people.debian.org/~branden/ |what he is. signature.asc Description: Digital signature
Bug#265829: xdm doesn't start at boot, but runs ok with /etc/init.d/xdm
reassign 265829 xserver-xfree86 retitle 265829 xserver-xfree86: [ati/r128] server sometimes fails to start with 'Memory manager initialization to (0,0) (288,0) failed' on Rage Mobility M3 AGP 2x rev 2 severity 265829 important tag 265829 + upstream help thanks On Wed, Sep 01, 2004 at 04:28:25PM +0200, David N. Welton wrote: Branden Robinson [EMAIL PROTECTED] writes: Well, memory management appears to be the culprit. Can you please follow-up with a list of kernel modules loaded when: 1) The X server fails to start with the above error message; and 2) The X server starts successfully. kernel modules before and after are exactly the same: Module Size Used by orinoco_cs 2 1 orinoco 53140 1 orinoco_cs hermes 15104 2 orinoco_cs,orinoco ds 23844 3 orinoco_cs yenta_socket 23360 1 pcmcia_core 73108 3 orinoco_cs,ds,yenta_socket binfmt_misc 12840 1 snd 64952 0 soundcore 11812 1 snd genrtc 8980 0 Color me stumped. I have no idea what is causing this. :( -- G. Branden Robinson| I suspect Linus wrote that in a Debian GNU/Linux | complicated way only to be able to [EMAIL PROTECTED] | have that comment in there. http://people.debian.org/~branden/ | -- Lars Wirzenius signature.asc Description: Digital signature
Re: new nv driver that should fix Xv extensions: please test!
Le lun 20/09/2004 à 18:02, Fabio Massimo Di Nitto a écrit : Hi everybody, thanks a lot for all the tests you have been done so far. I uploaded again a new nv driver that should fix the Xv extension here: http://people.no-name-yet.com/~fabbione/nv/i386/ Just tried it, at least I have Xv on my second head (Xinerama with All-In-Wonder + TNT2). Thanks a lot Fabian ! The only downside is the when the xine window is partially obscured on the second head, it seems to queue a lot of redraw events and consequently flashes a lot when redrawing, stopping all X activity for a short while. I don't see this on the 1st head. Xav
X Strike Force XFree86 SVN commit: r1833 - trunk/debian
Author: barbier Date: 2004-09-20 16:10:27 -0500 (Mon, 20 Sep 2004) New Revision: 1833 Modified: trunk/debian/TODO Log: Remove items fixed in r1822 and r1823. Modified: trunk/debian/TODO === --- trunk/debian/TODO 2004-09-20 20:04:07 UTC (rev 1832) +++ trunk/debian/TODO 2004-09-20 21:10:27 UTC (rev 1833) @@ -54,11 +54,6 @@ + Use /proc/hardware on m68k architecture to set a reasonable default mouse port. See URL: http://lists.debian.org/debian-68k/2004/08/msg00392.html. * Add FAQ entry describing Debian's plans in the X department. -* Check the contents of rules/xfree86.lst, it is used by GNOME and other - applications, and contain some bogus entries (like altwin:meta_super option). - (See #271259) -* The $oldlayouts variable in rules/xfree86 must list all layouts which are - only available in old layout. (See #270810) 4.3.0.dfsg.1-9 --
desagree
i dont want you in my computer! shut up!
[no subject]
y dont want you in my computer OK GO HOME STUPID BOYS Y DONT WANT TO AVE YOU IN MY COMPUTER CRASY BANDITOS I WOUD LIKE TO KIL YOU
Bug#263877: Various display artifacts in uxterm
On Wed, Sep 01, 2004 at 08:53:40AM -0700, Matt Zimmerman wrote: On Wed, Sep 01, 2004 at 04:47:23AM -0500, Branden Robinson wrote: Can someone please help me out with a better explanation of what the bug being reported here actually is? various display artifacts is hopelessly vague. I described the visual effect in my original submission. I'm attaching screenshots of them now. I wasn't really able to follow it, though; thanks for the screenshots. -- G. Branden Robinson|Of two competing theories or Debian GNU/Linux |explanations, all other things [EMAIL PROTECTED] |being equal, the simpler one is to http://people.debian.org/~branden/ |be preferred. -- Occam's Razor signature.asc Description: Digital signature
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
[no subject]
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
Re: X Strike Force XFree86 SVN commit: r1832 - in trunk/debian: . local
On Mon, Sep 20, 2004 at 03:04:09PM -0500, X Strike Force SVN Repository Admin
wrote:
[...]
-pIn releases previous to XFree86 4.3, combining several keymaps was
-difficult because keymaps had to be defined for each position. For instance
-codeus/code keymap was defined on first, second and third position,
-and this should have been done for all keymaps./p
+pemThanks to Denis Barbier for contributing this entry./em/p
-pKeymap layouts have been revisited in XFree86 4.3, and new definitions
-can now be used in whatever order so that codeus,ru/code and
-coderu,us/code use the same definitions. New definitions have been put
-into code class=filespec/etc/X11/xkb/symbols/pc//code and old ones are
-still available at the same place, ie. under the
-code class=filespec/etc/X11/xkb/symbols//code directory,/p
+pem[TODO: This entry needs to be more careful with keymap versus
layout
+terminology.
True, I will try to improve wording here.
Also, I don't understand the first paragraph or the first sentence
+of the second paragraph. Do the mentioned positions have to do with shift
+levels? Also, what relationship do shift levels have with groups? mdash;
+BR]/em/p
No, in my bogus terminology, position means the group number.
I wanted to tell that /etc/X11/xkb/symbold/us_group{2,3} were defined
to allow 'us' layout in 2nd or 3rd group, e.g. 'ru+us' layout is achieved
by combining 'ru' and 'us_group2'.
With this syntax, 'us+ru' needs 'us' and 'ru_group2' layouts (the latter
does not exist), so it is clear that all layouts need several
definitions, one for each group number. Comparing us_group2 and
us_group3 shows that this is ridiculous.
With the new layout format introduced in XFree86 4.3, layout definition
does not depend upon group number, so 'us+ru' and 'ru+us' use the same
symbol files.
Unfortunately, some layouts were not converted to this new format, and
can not be combined with other layouts.
BTW I had a look at capplets and gnome-applets bugs, and several of them
complain that trying to add these layouts does not work. Unfortunately,
these applications cannot easily fix these bugs, so I am going to
reassign them to xlibs.
In fact, xlibs can ship most (if not all) of those layouts in the new
format to help users who do need them, without any breakage.
The idea is to keep 099z_xkb_fix_rules_xfree86.diff unchanged so that
$oldlayouts in rules/xfree86 lists all layouts which are currently
shipped by xlibs in the old format, and get new symbol files from xorg
(more specifically from xkeyboard-config) into symbols/pc/.
With this setting, the layout is loaded from symbols/foo for the first
group, and from symbols/pc/foo for all other groups.
There is no breakage with single layouts because the same files are
loaded, and multiple layouts are allowed for these layouts.
Denis
[no subject]
YDON WAN YOUR TOOL BAR ON MY COMPUTER
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
Bug#267231: xlibs-data: Plane 1 in Compose file damaged
retitle 267231 xlibs-data: [en_US.UTF-8/Compose] Unicode Plane 1 characters damaged tag 267231 + upstream thanks On Sat, Aug 21, 2004 at 11:29:05AM +0200, Jan Willem Stumpel wrote: Package: xlibs-data Version: 4.3.0.dfsg.1-6 Severity: minor In /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose, the Unicode 'Plane 1' characters (above U, line 5577-5598) are damaged. E.g. the last character in the list, which should be U1D1C0 (hex f0 9d 87 80), is in reality UD1C0 (hex ed 87 80). Has this file spent some of its life in 16-bit Unicode form? It may very well have. Debian does not patch this file, so the damage must come from upstream. The damage might have been introduced by CVS; I'm not sure. I'd welcome a patch to fix it. -- G. Branden Robinson| The more you do, the more people Debian GNU/Linux | will dislike what you do. [EMAIL PROTECTED] | -- Gerfried Fuchs http://people.debian.org/~branden/ | signature.asc Description: Digital signature
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
Bug#271235: new nv driver that should fix Xv extensions: please test!
Fabio Massimo Di Nitto wrote: Can you reproduce it constantly? try to restart X and see if this happens again. Strange, after restarting (I have tried several times), I can't seem to use MPlayer with Xv no more. The same grey window appears. Perhaps I should add that my setup consists of an ATI Radeon 9100 AGP as my primary video card, and the GeForce2 MX PCI as a secondary card. Totem (based on Xine) works fine. Good! I forgot to add that the first time I run Totem the window where the video should play is completely blue. The second time everything plays ok. (But I belive this is an known and unrelated bug?). -- Cheers, Sven Arvidsson http://www.whiz.se
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
Bug#271235: new nv driver that should fix Xv extensions: please test!
Fabio Massimo Di Nitto wrote: Also, your setup is not really really common. I would try, as a workaround, to disable the ATI temporary, and see if everything works only with the nvidia. Do you think you can perform this test? Sure! Tried with the Geforce2 MX PCI solo, no luck. MPlayer with Xv - gray window. Totem (with Xine) - works, but with the same blue error described earlier. Also tried with a GeForce4 Ti 4200 AGP, the results were the same. -- Cheers, Sven Arvidsson http://www.whiz.se
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
Bug#264037: xserver-xfree86: Adding powerplay support to radeon?
On Wed, Sep 01, 2004 at 09:54:15AM -0700, obi wrote: On Wed, Sep 01, 2004 at 05:00:32AM -0500, Branden Robinson wrote: I'd feel most comfortable waiting until we package X.Org in the post-sarge timeframe to close this bug. Adding support for an option that's going to be renamed just adds headache for us and our users. However, if someone really wanted to seize hold of this issue in the next few days and babysit a patch ready for merge against the SVN trunk, I might be able to be persuaded otherwise. It's really all about someone taking ownership of the patch. At present, I don't have to do so. I'm not sure I understand completely what you mean. I'm not a Debian developer: is it just enough to submit a patch that sets the correct option (DynamicClocks instead of DynamicPM)? Is any other step required to take ownership of the patch? I attach here the patch that sets the option to be DynamicClocks (it's the same with just the option name changed). It needs to be turned into a patch in the debian/patches directory of the xfree86 source package and apply cleanly against the SVN trunk; please see the X Strike Force HACKING document[1] for more information. [1] http://necrotic.deadbeast.net/xsf/XFree86/HACKING.txt -- G. Branden Robinson| When I die I want to go peacefully Debian GNU/Linux | in my sleep like my ol' Grand [EMAIL PROTECTED] | Dad...not screaming in terror like http://people.debian.org/~branden/ | his passengers. signature.asc Description: Digital signature
new nv driver that should fix Xv extensions: please test!
Hi everybody, thanks a lot for all the tests you have been done so far. I uploaded again a new nv driver that should fix the Xv extension here: http://people.no-name-yet.com/~fabbione/nv/i386/ same drill as before. Please let me know asap how things look like. Here i could get Xv working on a RIVA TNT2 where Xv was not even enabled by the driver. Thanks! Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#240351: xserver-xfree86: Alt-Gr does not work anymore
On Tue, Aug 31, 2004 at 04:50:17PM +0200, Daniel Mentz wrote:
The most interesting information from your log file /var/log/XFree86.0.log
is
Couldn't load XKB keymap, falling back to pre-XKB keymap
I had the same problem and could solve it by installing the xlibs package.
Though the description of xlibs says that you don't need that package for
Debian 3.1 (sarge),
It does not[1].
Package: xlibs
Section: libs
Architecture: all
Depends: libice6, libsm6, libx11-6, libxext6, libxft1, libxi6, libxmu6,
libxmuu1, libxp6, libxpm4, libxrandr2, libxt6, libxtrap6, libxtst6, xlibs-data,
${misc:Depends}
Conflicts: xbase, xlib, xpm4g, fvwm-common, qcad ( 1.4.6-1), xbase-clients
( 4.0), xcontrib ( 4.0), xlib6g ( 4.0), xlib6g-dev ( 4.0), xsm ( 4.0)
Replaces: xbase, xlib, xpm4g, fvwm-common, qcad ( 1.4.6-1), xbase-clients (
4.0), xcontrib ( 4.0), xlib6g ( 4.0), xlib6g-dev ( 4.0), xsm ( 4.0)
Description: X Window System client libraries metapackage and XKB data
This package smooths upgrades from Debian 3.0 by depending on the individual
library packages into which each shared object formerly contained in this
package has been split.
.
This package is only depended upon by packages that haven't yet been compiled
against the new shared library packages.
.
This package also contains configuration data used by the X Keyboard
Extension (XKB). Other architecture-independent data used by X libraries can
be found in the xlibs-data package.
Moreover, the package's extended description hasn't changed in quite some
time[2]:
1branden Package: xlibs
1branden Section: libs
1044branden Architecture: all
1044branden Depends: libice6, libsm6, libx11-6, libxext6, libxft1,
libxi6, libxmu6, libxmuu1, libxp6, libxpm4, libxrandr2, libxt6, libxtrap6,
libxtst6, xlibs-data, ${misc:Depends}
1249branden Conflicts: xbase, xlib, xpm4g, fvwm-common, qcad (
1.4.6-1), xbase-clients ( 4.0), xcontrib ( 4.0), xlib6g ( 4.0),
xlib6g-dev ( 4.0), xsm ( 4.0)
1249branden Replaces: xbase, xlib, xpm4g, fvwm-common, qcad ( 1.4.6-1),
xbase-clients ( 4.0), xcontrib ( 4.0), xlib6g ( 4.0), xlib6g-dev (
4.0), xsm ( 4.0)
1044branden Description: X Window System client libraries metapackage and
XKB data
1044branden This package smooths upgrades from Debian 3.0 by depending
on the individual
1044branden library packages into which each shared object formerly
contained in this
1044branden package has been split.
1branden .
1044branden This package is only depended upon by packages that haven't
yet been compiled
1044branden against the new shared library packages.
1branden .
1044branden This package also contains configuration data used by the X
Keyboard
1044branden Extension (XKB). Other architecture-independent data used
by X libraries can
1044branden be found in the xlibs-data package.
1044branden
We can furthermore see that revision 1044 was committed over six months
ago, and was itself a merge[3], which means that the actual current language
of the extended description is older still.
r1044 | branden | 2004-02-16 12:40:33 -0500 (Mon, 16 Feb 2004) | 7 lines
Merge revisions 1042:HEAD from branches/4.3.0/sid-branched-properly onto
trunk.
NOTE: This wasn't a pure merge; there were 67 files with conflicts that
were resolved, and some obsolescent files (on the trunk, not new from the
merge) were deleted.
Please do not spread disinformation on this mailing list.
(I do admit that the only depended upon phrase is overbroad. Things
which directly parse XKB data files should also depend on this package --
while there are almost vanishingly few of those compared to packages that
have a shared library dependency on one of the libraries formerly in xlibs,
the language could be more precise. The fact remains that the package
description in no way asserts that you don't need [it] for Debian 3.1.)
[1] svn cat svn://necrotic.deadbeast.net/xfree86/trunk/debian/control
[2] svn blame svn://necrotic.deadbeast.net/xfree86/trunk/debian/control
[3] svn log -r 1044 svn://necrotic.deadbeast.net/xfree86/trunk/debian/control
--
G. Branden Robinson| There's something wrong if you're
Debian GNU/Linux | always right.
[EMAIL PROTECTED] | -- Glasow's Law
http://people.debian.org/~branden/ |
signature.asc
Description: Digital signature
X Strike Force XFree86 SVN commit: r1831 - people/fabbione/nv-driver-backport/debian/patches
Author: fabbione
Date: 2004-09-20 07:11:14 -0500 (Mon, 20 Sep 2004)
New Revision: 1831
Modified:
people/fabbione/nv-driver-backport/debian/patches/030_Xserver_and_driver_region_primitive_fixups.diff
Log:
Fix Xv extensions.
Modified:
people/fabbione/nv-driver-backport/debian/patches/030_Xserver_and_driver_region_primitive_fixups.diff
===
---
people/fabbione/nv-driver-backport/debian/patches/030_Xserver_and_driver_region_primitive_fixups.diff
2004-09-18 18:54:02 UTC (rev 1830)
+++
people/fabbione/nv-driver-backport/debian/patches/030_Xserver_and_driver_region_primitive_fixups.diff
2004-09-20 12:11:14 UTC (rev 1831)
@@ -11,9 +11,9 @@
Revert same REGION_EQUAL change in trident driver.
-diff -Naurd xc.orig/programs/Xserver/hw/xfree86/drivers/ati/atimach64xv.c
xc/programs/Xserver/hw/xfree86/drivers/ati/atimach64xv.c
xc.orig/programs/Xserver/hw/xfree86/drivers/ati/atimach64xv.c
2004-09-15 08:20:24.0 +
-+++ xc/programs/Xserver/hw/xfree86/drivers/ati/atimach64xv.c 2004-09-15
08:21:40.0 +
+diff -Naurd xc-old/programs/Xserver/hw/xfree86/drivers/ati/atimach64xv.c
xc/programs/Xserver/hw/xfree86/drivers/ati/atimach64xv.c
+--- xc-old/programs/Xserver/hw/xfree86/drivers/ati/atimach64xv.c
2004-09-20 11:09:00.0 +
xc/programs/Xserver/hw/xfree86/drivers/ati/atimach64xv.c 2004-09-20
11:10:14.0 +
@@ -34,6 +34,38 @@
#define MAKE_ATOM(string) MakeAtom(string, strlen(string), TRUE)
#define MaxScale (CARD32)(CARD16)(-1)
@@ -62,9 +62,9 @@
{
REGION_COPY(pScreen, pATI-VideoClip, pClip);
if (pATI-AutoPaint)
-diff -Naurd xc.orig/programs/Xserver/hw/xfree86/drivers/ati/r128_video.c
xc/programs/Xserver/hw/xfree86/drivers/ati/r128_video.c
xc.orig/programs/Xserver/hw/xfree86/drivers/ati/r128_video.c
2004-09-15 08:20:24.0 +
-+++ xc/programs/Xserver/hw/xfree86/drivers/ati/r128_video.c2004-09-15
08:21:40.0 +
+diff -Naurd xc-old/programs/Xserver/hw/xfree86/drivers/ati/r128_video.c
xc/programs/Xserver/hw/xfree86/drivers/ati/r128_video.c
+--- xc-old/programs/Xserver/hw/xfree86/drivers/ati/r128_video.c
2004-09-20 11:09:02.0 +
xc/programs/Xserver/hw/xfree86/drivers/ati/r128_video.c2004-09-20
11:10:14.0 +
@@ -23,6 +23,38 @@
#define TIMER_MASK (OFF_TIMER | FREE_TIMER)
@@ -113,9 +113,9 @@
REGION_COPY(pScrn-pScreen, pPriv-clip, clipBoxes);
/* draw these */
xf86XVFillKeyHelper(pScrn-pScreen, pPriv-colorKey, clipBoxes);
-diff -Naurd xc.orig/programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c
xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c
xc.orig/programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c
2004-09-15 08:20:24.0 +
-+++ xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c 2004-09-15
08:21:40.0 +
+diff -Naurd xc-old/programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c
xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c
+--- xc-old/programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c
2004-09-20 11:09:00.0 +
xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c 2004-09-20
11:10:14.0 +
@@ -20,6 +20,38 @@
#define TIMER_MASK (OFF_TIMER | FREE_TIMER)
@@ -164,44 +164,38 @@
{
REGION_COPY(pScrn-pScreen, pPriv-clip, clipBoxes);
/* draw these */
-diff -Naurd xc.orig/programs/Xserver/hw/xfree86/drivers/nv/nv_video.c
xc/programs/Xserver/hw/xfree86/drivers/nv/nv_video.c
xc.orig/programs/Xserver/hw/xfree86/drivers/nv/nv_video.c 2004-09-15
08:19:03.0 +
-+++ xc/programs/Xserver/hw/xfree86/drivers/nv/nv_video.c 2004-09-15
08:23:27.0 +
-@@ -451,6 +451,41 @@
+diff -Naurd xc-old/programs/Xserver/hw/xfree86/drivers/nv/nv_video.c
xc/programs/Xserver/hw/xfree86/drivers/nv/nv_video.c
+--- xc-old/programs/Xserver/hw/xfree86/drivers/nv/nv_video.c 2004-09-20
11:09:00.0 +
xc/programs/Xserver/hw/xfree86/drivers/nv/nv_video.c 2004-09-20
11:10:14.0 +
+@@ -451,6 +451,35 @@
return adapt;
}
+/*
+ * RegionsEqual
+ */
-+static Bool RegionsEqual
-+(
-+RegionPtr A,
-+RegionPtr B
-+)
++static Bool RegionsEqual(reg1, reg2)
++RegionPtr reg1;
++RegionPtr reg2;
+{
-+int *dataA, *dataB;
-+int num;
++int i, num;
++BoxPtr rects1, rects2;
+
-+num = REGION_NUM_RECTS(A);
-+if (num != REGION_NUM_RECTS(B))
-+return FALSE;
++if (reg1-extents.x1 != reg2-extents.x1) return FALSE;
++if (reg1-extents.x2 != reg2-extents.x2) return FALSE;
++if (reg1-extents.y1 != reg2-extents.y1) return FALSE;
++if (reg1-extents.y2 != reg2-extents.y2) return FALSE;
+
-+if ((A-extents.x1 != B-extents.x1) ||
-+(A-extents.x2 != B-extents.x2) ||
-+(A-extents.y1 != B-extents.y1) ||
-+
Bug#272493: libxpm4: Three exploitable overflows in XPM handling
Package: libxpm4 Version: 4.3.0-0pre1v5.49.200406160839 Severity: grave Tags: security Justification: user security hole There are three exploitable stack and integer overflows in the XPM handling code shipped with XFree: Full details can be found in this advisory from Chris Evans which I copied at the end of this mail for archival purposes. Cheers, Moritz http://scary.beasts.org/security/CESA-2004-003.txt libXpm multiple image parsing flaws === Programs affected: libXpm, and any programs which use libXpm to decode XPM files. For example, the GIMP seems to use libXpm. Severity: Compromise of account used to browse malicious XPM file. CAN identifier(s): CAN-2004-0687 and CAN-2004-0688 Fixed: X.ORG release 6.8.1 contains fixes. This advisory lists code flaws discovered by inspection of the libXpm code. The specific version of libXpm discussed is the release that comes with the initial X.ORG X11 system source code release. However, these flaws seem to exist in older versions. Flaw 1. Stack-based overflow in xpmParseColors (parse.c). This is CAN-2004-0687 Careless use of strcat() in both the XPMv1 and XPMv2/3 parsing code leads to a stack based overflow that should be exploitable. There are minor complications due to stack layout; the buffer being overflowed in fact typically overflows into another buffer that is used to populate the overflowed buffer. This should not prevent exploitation, however. Demo XPM: http://scary.beasts.org/misc/doom.xpm Flaw 2. Integer overflow allocating colorTable in xpmParseColors (parse.c) - probably a crashable but not exploitable offence. Here: This is CAN-2004-0688 colorTable = (XpmColor *) XpmCalloc(ncolors, sizeof(XpmColor)); ncolors would seem to come from the (untrusted) XPM file. In fact, multiple integer overflow problems seem to exist. Some may well be exploitable. Note that the following may not be an exhaustive list: a) XpmCreateImageFromXpmImage: multiple possible overflow, e.g.: image_pixels = (Pixel *) XpmMalloc(sizeof(Pixel) * image-ncolors); (ncolors is user-supplied) b) CreateXImage: *image_return = XCreateImage(display, visual, depth, format, 0, 0, width, height, bitmap_pad, 0); (width and height are user-supplied, possibly other variables too) c) ParsePixels: iptr2 = (unsigned int *) XpmMalloc(sizeof(unsigned int) * width * height); (width and height are user-supplied) d) ParseAndPutPixels and ParsePixels: cidx[char1][(unsigned char)colorTable[a].string[1]] = a + 1; (possibly, char1 might be negative, and access the cidx array out of bounds) Flaw 3. Stack overflow reading pixel values in ParseAndPutPixels (create.c) as well as ParsePixels (parse.c). Should be exploitable. This is CAN-2004-0687 A user-supplied number of bytes are stuffed into a fixed-size buffer (typically 8192 bytes). The user gets to choose how many bytes to put into this buffer via the number of bytes per pixel XPM value. Demo XPM: http://scary.beasts.org/misc/doom2.xpm -- System Information: Debian Release: 3.0 Architecture: i386 Kernel: Linux anton 2.4.26 #1 SMP Wed Jun 30 12:43:43 CEST 2004 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] Versions of packages libxpm4 depends on: ii libc6 2.3.2-8GNU C Library: Shared libraries an -- debconf-show failed
Bug#272496: [radeon] resume fails on iBook2
Package: xserver-xfree86 Version: 4.3.0.dfsg.1-7 When suspending my iBook the resume fails after resuming the sungem ethernet if I had been running X when suspending. Not runing X or downgrading to xserver-xfree86-4.3.0.dfsg.1-4 from testing fixes the problem. This is running various 2.6 kernels (kernel-image-2.6.8 from debian, various homegrown recent 2.6 kernels). lspci output below: :00:0b.0 Host bridge: Apple Computer Inc. UniNorth/Pangea AGP :00:10.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] 0001:01:0b.0 Host bridge: Apple Computer Inc. UniNorth/Pangea PCI 0001:01:17.0 ff00: Apple Computer Inc. KeyLargo/Pangea Mac I/O 0001:01:18.0 USB Controller: Apple Computer Inc. KeyLargo/Pangea USB 0001:01:19.0 USB Controller: Apple Computer Inc. KeyLargo/Pangea USB 0002:02:0b.0 Host bridge: Apple Computer Inc. UniNorth/Pangea Internal PCI 0002:02:0e.0 FireWire (IEEE 1394): Apple Computer Inc. UniNorth/Pangea FireWire 0002:02:0f.0 Ethernet controller: Apple Computer Inc. UniNorth/Pangea GMAC (Sun GEM)
Xsession doesn't use UMASK setting from /etc/login.defs
Hi,
After a fresh sarge install, I'm having problems with umask settings. In
/etc/login.defs I set umask to 002, and that works for logging in on the
console or remote via ssh. However, if I use {g,x,k}dm I keep getting an
umask of 022, because Xsession is started by the display manager which
has a default umask of 022.
It seems that Xsession doesn't change the UMASK at all. Should it do so?
If not, which program should set the umask during a graphical login?
Wouter
Bug#271235: new nv driver that should fix Xv extensions: please test!
Fabio Massimo Di Nitto wrote: Hi everybody, thanks a lot for all the tests you have been done so far. I uploaded again a new nv driver that should fix the Xv extension here: http://people.no-name-yet.com/~fabbione/nv/i386/ same drill as before. Please let me know asap how things look like. Using a GeForce2 MX, the new driver works better, but there are still problems. I could play a video with MPlayer using Xv the first time I tried, the second time all I get is a grey window, same as the original bug :-( Totem (based on Xine) works fine. Please let me know if you need additional info. -- Cheers, Sven Arvidsson http://www.whiz.se
Bug#272493: DSA and sid uploads needed (was: Re: Bug#272493: libxpm4: Three exploitable overflows in XPM handling)
On Mon, Sep 20, 2004 at 02:02:11PM +0200, Moritz M??hlenhoff wrote: There are three exploitable stack and integer overflows in the XPM handling code shipped with XFree: Full details can be found in this advisory from Chris Evans which I copied at the end of this mail for archival purposes. Branden Robinson has the patch and is handling the DSA for woody; I understnad he is also handling the 4.3 upload for sid. Branden? -- Daniel Stone[EMAIL PROTECTED] Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
Re: Bug#271235: new nv driver that should fix Xv extensions: please test!
On Mon, 20 Sep 2004, Sven Arvidsson wrote: Fabio Massimo Di Nitto wrote: Hi everybody, thanks a lot for all the tests you have been done so far. I uploaded again a new nv driver that should fix the Xv extension here: http://people.no-name-yet.com/~fabbione/nv/i386/ same drill as before. Please let me know asap how things look like. Using a GeForce2 MX, the new driver works better, but there are still problems. I could play a video with MPlayer using Xv the first time I tried, the second time all I get is a grey window, same as the original bug :-( Can you reproduce it constantly? try to restart X and see if this happens again. Totem (based on Xine) works fine. Good! Thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Bug#271235: new nv driver that should fix Xv extensions: please test!
On Mon, 20 Sep 2004, Sven Arvidsson wrote: Fabio Massimo Di Nitto wrote: Can you reproduce it constantly? try to restart X and see if this happens again. Strange, after restarting (I have tried several times), I can't seem to use MPlayer with Xv no more. The same grey window appears. Perhaps I should add that my setup consists of an ATI Radeon 9100 AGP as my primary video card, and the GeForce2 MX PCI as a secondary card. Totem (based on Xine) works fine. Good! I forgot to add that the first time I run Totem the window where the video should play is completely blue. The second time everything plays ok. (But I belive this is an known and unrelated bug?). It sounds to me like if players have problems selecting the correct viewport. Also, your setup is not really really common. I would try, as a workaround, to disable the ATI temporary, and see if everything works only with the nvidia. Do you think you can perform this test? Thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
mtrr and ati-radeon
Hello. My question concerns xserver-common 4.3.0.dfsg.1-4 from Debian testing. The graphics-card in my laptop is an ATI Radeon Mobility M6: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA]) Subsystem: Mitac: Unknown device 8170 Flags: bus master, stepping, 66Mhz, medium devsel, latency 64, IRQ 11 Memory at 9000 (32-bit, prefetchable) [size=128M] I/O ports at c000 [size=256] Memory at e000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at unassigned [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Capabilities: [50] Power Management version 2 For some time now, the following warning has turned up in my X log-file: (WW) RADEON(0): Failed to set up write-combining range (0x9000,0x100) Searching on the web suggests that this warning derives from some mis-configuration of MTRR support in the kernel, and indeed that is confirmed by the presence of the following in /var/log/messages: kernel: mtrr: 0x9000,0x100 overlaps existing 0x9000,0x20 Cat /proc/mtrr gives: reg00: base=0x ( 0MB), size= 512MB: write-back, count=1 reg01: base=0x9000 (2304MB), size= 2MB: write-combining, count=1 reg02: base=0xa000 (2560MB), size= 64MB: write-combining, count=1 And from the X log-file: (--) RADEON(0): Chipset: ATI Radeon Mobility M6 LY (AGP) (ChipID =0x4c59) (--) RADEON(0): Linear framebuffer at 0x9000 (--) RADEON(0): VideoRAM: 16384 kByte (64 bit DDR SDRAM) X is perfectly usable despite this warning, but my understanding is that MTRR properly configured can give really substantial performance gains under X and of course I'd like to be able to take advantage of those. I've read mtrr.txt in the kernel Documentation directory, and so I know in principle how to create MTRRs from the shell, using /proc/mtrr. However, I don't understand the principles behind this well enough to know what ranges to set up. If there were someone here who could advise me about this, or who could point me to something useful to read, I'd be very grateful. Thanks for all your work, Jim
Re: new nv driver that should fix Xv extensions: please test!
On Mon, 20 Sep 2004, Christoph Hellwig wrote: On Mon, Sep 20, 2004 at 02:24:00PM +0200, Fabio Massimo Di Nitto wrote: Hi everybody, thanks a lot for all the tests you have been done so far. I uploaded again a new nv driver that should fix the Xv extension here: http://people.no-name-yet.com/~fabbione/nv/i386/ Do you also have a ppc binary? They are up now: http://people.no-name-yet.com/~fabbione/nv/powerpc/ sorry.. the 2 files are bigger than the others because they haven't be stripped from the debugging symbols, but they will work as the normal one. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Bug#271235: new nv driver that should fix Xv extensions: please, test!
Hello Fabio, The new driver doesn't seem to work on my GeForce2 MX400. I encounter the same behavior as before from both mplayer (gray window) and tvtime. Even restarted X a few times, didn't help. Xine works fine. Best regards, Andrei -- [EMAIL PROTECTED] # http://movzx.net # ICQ: 52641547
Re: Bug#269025: new nv driver that should fix Xv extensions: please test!
On Mon, Sep 20, 2004 at 02:24:00PM +0200, Fabio Massimo Di Nitto [EMAIL PROTECTED] wrote: Hi everybody, thanks a lot for all the tests you have been done so far. I uploaded again a new nv driver that should fix the Xv extension here: http://people.no-name-yet.com/~fabbione/nv/i386/ same drill as before. Please let me know asap how things look like. Hi, It doesn't change anything for me : I still have the problems with mplayer. -- | Lucas Nussbaum | [EMAIL PROTECTED][EMAIL PROTECTED]GPG: 1024D/023B3F4F | | jabber: [EMAIL PROTECTED] http://www.lucas-nussbaum.net | | fingerprint: 075D 010B 80C3 AC68 BD4F B328 DA19 6237 023B 3F4F |
Bug#237877: use DisplaySize to set dpi
On Wed, Sep 01, 2004 at 04:39:17PM -0400, Andrew Pimlott wrote: On Wed, Sep 01, 2004 at 04:57:37AM -0500, Branden Robinson wrote: [Are you subscribed to this list?] Do you mean to this bug? No, I haven't learned how to do that yet. No, I mean to the debian-x mailing list, to which all non-quiet bug traffic against xfree86, xft, xrender, and render packages go. On Fri, Aug 06, 2004 at 02:35:23PM -0400, Andrew Pimlott wrote: Also, has anyone asked the X developers for a soft version of -dpi or DisplaySize? It seems like a trivial feature. Sure; I've considered implementing it (-softdpi) myself. So far, not enough round tuits for it. The patch by Gus (if you reverse the second half) looks like an expedient solution, unless you think it will confuse people. That just changes one hard-coded default for another. I think -softdpi would be superior to both. -- G. Branden Robinson|It's extremely difficult to govern Debian GNU/Linux |when you control all three branches [EMAIL PROTECTED] |of government. http://people.debian.org/~branden/ |-- John Feehery signature.asc Description: Digital signature
Bug#271235: Tried the last nv drivers : not better with mplayer.
Juts to let you know. Thanks for the work anyway. -- eric
[no subject]
yam too ungry to have you in my computer! y have no time and no place for you for me , you are piracy (pirates , salopards ,dégagez ,fumiers)
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
[no subject]
DEGAGEZ DE MON ORDINATEUR SALOPARDS FUMIERS
