Bug#420679: A fix.
tags 420679 +patch stop Redhat has a patch for this issue: http://cvs.fedora.redhat.com/viewcvs/rpms/xorg-x11-server/devel/xserver-1.3.0-less-randr-fakerama.patch?rev=1.1&sortby=date&view=auto Given the author of the patch, it looks like a good bet until it's fixed in a release upstream. Zephaniah E. Hull. -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. signature.asc Description: Digital signature
Bug#350389: New evdev driver sucks. [patch]
Package: xserver-xorg Version: 6.9.0.dfsg.1-4 Tags: patch Severity: wishlist To put it very bluntly, the new evdev driver is a regression in a number of ways, from lack of xkb support, to no way to configure mice handling, and most importantly, to the complete lack of any sane way to specify devices. This is not so easily fixed, but the patches contained in https://bugs.freedesktop.org/show_bug.cgi?id=5696 do the job nicely. Comments and suggestions are welcome, but, to be quite blunt, the current situation has obviously (see bugs #347681, #349586, #347950, #346460, #347677) caused problems with the userbase. The patch in question should bring things back up to spec. Zephaniah E. Hull. -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. "First they came for the Jews, and I didn't speak out - because I was not a jew. Then they came for the Communists, and I did not speak out - because I was not a Communist. Then they came for the trade unionists, and I did not speak out - because I was not a trade unionist. Then they came for me and there was no one left to speak for me!" - Pastor Niemoeller - victim of Hitler's Nazis signature.asc Description: Digital signature
Re: evdev Keyboard Driver: Support for extra keys?
On Tue, Jun 01, 2004 at 03:44:36AM -0500, Branden Robinson wrote: > On Mon, May 31, 2004 at 09:55:58PM +0200, Sebastian Kapfer wrote: > > CC'ing Zephaniah E. Hull, who seems to be the person who contributed the > > patch in question. > [...] > > I hope I'm asking this question in the right place, since the evdev > > support patch seems to be Debian specific. I was trying to get my > > keyboard (Sun Type 6 USB) to work with the evdev driver, and I found a > > whole lot of keys reporting scancode 7, even more than in "regular" > > operation, without the evdev stuff. Then I read these lines in the > > patch: > [...] > > ... which could explain that. Is there a specific reason why these > > codes are mapped to KEY_UNKNOWN? I mean, if Linux recognizes them > > (which I'm not sure about -- is there a way to verify that besides > > hexdumping /dev/input/event*?), it would be cool to pass them on to the > > user. > > I'm going to have to defer to Zeph on this one. > > Zeph, can you shed some light on this, please? Er, the answer is quite simple really. I could find nothing to map them /TO/ on the X side of things. This could simply be my missing something, but I really could find no keycodes to map those to. Nor someplace to throw unknown codes on mass. Does anyone have some bright ideas on how to handle them? -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. The story includes this array of huge rhymes-with-hell machines, all running screensavers, the power and SAN cables neatly run between them... and the disused tape-storage closet stuffed with old Sun boxen still humming quietly away. - adb in ASR on rumours of a flawless SunOS to NT site cutover. signature.asc Description: Digital signature
Re: problem with left-handed mouse on X - is GPM to blame or is it X?
On Mon, May 10, 2004 at 04:10:18PM -0500, Branden Robinson wrote: > On Fri, Apr 30, 2004 at 10:14:32AM +0300, Martin-?ric Racine wrote: > > 1) The information about using GPM's -B option is incorrect. As you can see > > from the enclosed configs, I already use -B 321, but this is ignored by X. > > Zeph, can you comment on this? > > Is -B 321 really broken, or only broken for the "raw" repeat type? I > think I can imagine why it might not work for the "raw" repeat type. > > Honnestly, the correct action would be for X to follow the button order > > configured for GPM. I really wonder why that fails. > > If you use the "raw" repeat type, there may be no way it *can* work. > > Zeph, can you help clear up this issue? Please see the last message, where I covered just this. Raw mode repeats byte for byte, it does not attempt to do ANYTHING to them. In addition, he is repeating a PS2 protocol, with all the problems involved in that. I will say it once more, this is a case of user error. The proper configuration for this is having gpm not repeat, and both X and gpm reading from /dev/input/mice, with X doing some button remapping in whatever manner is now suggested. If 'xmodmap -e "pointer = 3 2 1"' is no longer the suggested means, what is? -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. Knghtbrd: Eww, find a better name, the movie sucked.. Mercury: The engine is better than the movie
Re: problem with left-handed mouse on X - is GPM to blame or is it X?
On Thu, Apr 29, 2004 at 12:29:35PM +0300, Martin-?ric Racine wrote: > Greetings, > > Given how everyone in this family is left-handed, I recently got around > inverting the order of the mouse buttons in GPM; works great in console. > > Since GPM is setup as a repeater for X, I thought that X would also end up > defaulting to inverted button order, but it doesn't. > > repeat_type=raw > type=imps2 > Section "InputDevice" > Option "Device""/dev/gpmdata" > Option "Protocol" "ImPS/2" > EndSection This is user error. The raw repeat type is something that I am beginning to think is more of a bug then a feature, it does a byte for byte repeat, making no changes to the byte stream. Further more, it seems to be most commonly used with the PS/2 protocols, which, is another rant about two-way communications on a FIFO. Kill the repeat type, have X read from /dev/input/mice as well, and use xmodmap in your ~/.xsession. -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. So, you are thinking am Communist ? Deal, Comerade ! -- Chris on ASR. signature.asc Description: Digital signature
Re: who is the author of the Linux evdev patch to lnx_kbd.c?
On Sun, Feb 29, 2004 at 10:34:13PM -0500, Branden Robinson wrote: > On Fri, Feb 27, 2004 at 03:19:07PM -0500, Zephaniah E. Hull wrote: > > I should have put a note on it when I wrote it. > > You did put a copyright notice in one file, but there was no license > information, so that was needed. Also, your work was split up into 3 > patches. > > > The same applies to the entirety of the evdev patch, including the > > evdev helper stuff and the mice patch. > > I've put the following legalese into SVN. This information is, at > present, just in the patch annotation, not in the source code itself. > > Copyright 2003 Zephaniah E. Hull. > > Permission is hereby granted, free of charge, to any person obtaining a > copy of this software and associated documentation files (the "Software"), > to deal in the Software without restriction, including without limitation > the rights to use, copy, modify, merge, publish, distribute, sublicense, > and/or sell copies of the Software, and to permit persons to whom the > Software is furnished to do so, subject to the following conditions: > > The above copyright notice and this permission notice shall be included in > all copies or substantial portions of the Software. > > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > ZEPHANIAH E. HULL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, > WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF > OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE > SOFTWARE. > > Except as contained in this notice, the name of Zephaniah E. Hull shall > not be used in advertising or otherwise to promote the sale, use or other > dealings in this Software without prior written authorization from > Zephaniah E. Hull. > > Does that look all right? It looks perfect. As a side note, what is the best way of extracting these patches from SVN so I can put the current versions (with the copyright notices) up for non-Debian users? -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. "Pshaw! *I* am a paid-up member of the Mystic Order of Arachnid Vigilance." "Please. Why don't you go fight evil somewhere else? I'm trying to sleep here." -- Rodger Donaldson and Eric The Read in the Scary Devil Monastery signature.asc Description: Digital signature
Re: who is the author of the Linux evdev patch to lnx_kbd.c?
On Fri, Feb 27, 2004 at 02:47:17PM -0500, Branden Robinson wrote: > On Thu, Feb 26, 2004 at 08:51:25PM -0500, Zephaniah E. Hull wrote: > > On Thu, Feb 26, 2004 at 01:55:40PM -0500, Branden Robinson wrote: > > > The evdev patch to lnx_kbd.c (attached) in XFree86 4.3.0 is fairly > > > large, and contains no author information. > > > > > > Furthermore, the changes are substantial enough that copyright probably > > > resides in them. > > > > > > Can either of you guys shed some light on who wrote this code? > > > > Copyright 2003 Zephaniah E. Hull. > > Under the old X license. > > (Or did I do most of that work in 2002?) > > Great, thank you! I should have put a note on it when I wrote it. The same applies to the entirety of the evdev patch, including the evdev helper stuff and the mice patch. > > -- > G. Branden Robinson| If you have the slightest bit of > Debian GNU/Linux | intellectual integrity you cannot > [EMAIL PROTECTED] | support the government. > http://people.debian.org/~branden/ | -- anonymous -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. * Culus thinks we should go to trade shows and see how many people we can kill by throwing debian cds at them signature.asc Description: Digital signature
Re: who is the author of the Linux evdev patch to lnx_kbd.c?
On Thu, Feb 26, 2004 at 01:55:40PM -0500, Branden Robinson wrote:
> The evdev patch to lnx_kbd.c (attached) in XFree86 4.3.0 is fairly
> large, and contains no author information.
>
> Furthermore, the changes are substantial enough that copyright probably
> resides in them.
>
> Can either of you guys shed some light on who wrote this code?
Copyright 2003 Zephaniah E. Hull.
Under the old X license.
(Or did I do most of that work in 2002?)
--
1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.
"I would rather spend 10 hours reading someone else's source code than
10 minutes listening to Musak waiting for technical support which
isn't."
(By Dr. Greg Wettstein, Roger Maris Cancer Center)
signature.asc
Description: Digital signature
Bug#233933: X server 4.3 stalls for a few seconds when switching from console back to X
On Sat, Feb 21, 2004 at 02:20:56PM -0500, Branden Robinson wrote: > On Sat, Feb 21, 2004 at 11:07:06AM -0500, Zephaniah E. Hull wrote: > > The protocol you need to use is the one gpm calls ms3, X calls it > > IntelliMouse, which is the serial version of the IMPS/2 protocol, > > however it is NOT bi-directional, it has 3 buttons, a wheel, and it is > > safe to use over the fifo. > > > > Zeph, > > Thanks for shedding some light on this. > > Should I interpret the above to mean "this bug should be closed as due > to user misconfiguration"? Yes. -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. If the user points the gun at his foot and pulls the trigger, it is our job to ensure the bullet gets where it's supposed to. signature.asc Description: Digital signature
Bug#233933: X server 4.3 stalls for a few seconds when switching from console back to X
On Sat, Feb 21, 2004 at 02:24:35PM +0100, Raphael Zimmerer wrote: > I tried to track down the problem. I found out that XFree86 spends > lots of time in ps2Reset() at /hw/xfree86/input/mouse/pnp.c. > > My pointer-device was configured to take data from gpm: > > Section "InputDevice" Identifier "Configured Mouse" > Driver "mouse" > Option "CorePointer" > Option "Device" "/dev/gpmdata" > Option "Protocol""PS/2" I have said it MANY times, and I will say it again. There is exactly ONE protocol which it is valid to talk to gpm over /dev/gpmdata with, and that protocol is NOT PS/2. No matter how much people scream and yell about how it works fine, this is a perfect example of why trying to use a bi-directional protocol over a fifo DOES NOT WORK. The protocol you need to use is the one gpm calls ms3, X calls it IntelliMouse, which is the serial version of the IMPS/2 protocol, however it is NOT bi-directional, it has 3 buttons, a wheel, and it is safe to use over the fifo. -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. If books were designed by Microsoft, the Anarchist's Cookbook would explode when you read it. -- Mark W. Schumann in the Scary Devil Monastery. signature.asc Description: Digital signature
Bug#169427: without "AllowMouseOpenFail" causes X _keyboard_ to fail silently if _mouse_ is not plugged in
On Fri, Dec 20, 2002 at 04:17:59PM +0100, Frank Murphy wrote:
> > P.R. Patil writes:
> > > Dear All,
> > > If ps mouse is not connected to the pc then it hangs the kbd.
> > > Can any one solve the problem?Thanks and Regds,
> >
> > This is not the fault of the Xserver.
> >
> > It is partly the fault of the archaic hardware design:
> > When you open the PS/2 mouse device without a mouse being connected the
> > chipset will generate a fault data byte after a long timeout period. Since
> > this data byte doesn't get serviced (appearantly no interrupt is generated)
> > the keyboard/mouse controller doesn't generate any interrupt for any
> > further events. If at all the kernel needs to handle this.
> >
> > The funny thing is: if you access the keyboard thru an ioctl (ie when
> > terminating X or by setting the keyboard rate) the fault package is
> > serviced and the keyboard starts working again.
> >
> > If at all this problem needs to be handled in the kernel.
> >
> > Egbert.
>
> So it seems that this bug should be reassigned to the Linux kernel. I'd be
> interested to know if those having problems are able to use gpm, or some
> other text-based, mouse-enabled programs without killing the keyboard.
This is a problem that I hit a while back in gpm, it is a simple one but
also one nearly impossible to deal with in X, only vaguely possible to
deal with in gpm.
Basicly it works like this, on some motherboards, with /some/ kernel
versions (I /believe/ it is no longer an issue with 2.4.20, probably
fixed a little before that, but someone who can reproduce this please
check), if there is no PS/2 mouse attached, and we attempt to write to
/dev/psaux, we lose.
The write blocks forever, even with non-blocking IO enabled, and the
keyboard is dead.
HOWEVER, if the program in question is killed and thus the device
closed, keyboard access remains.
How I solved this in gpm was straight forward enough, I set an alarm to
go off 5 seconds after each right, and when the write returns I cancel
it, if the write actually blocks then the alarm kills gpm and people get
the keyboard back.
Obviously, that same trick is really not much of an option for X.
Welcome to a hell that can only be fixed in the kernel. (=:]
Zephaniah E. Hull.
Debian gpm maintainer.
>
> Frank
--
1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.
Hey, if you've mlock'ed more than your available memory, there's nothing
the VM layer can do. Except maybe a nice printk("Kiss your *ss goodbye");
-- Linus
pgp9rwEbHEwL9.pgp
Description: PGP signature
Bug#169427: without "AllowMouseOpenFail" causes X _keyboard_ to fail silently if _mouse_ is not plugged in
On Fri, Dec 20, 2002 at 04:17:59PM +0100, Frank Murphy wrote:
> > P.R. Patil writes:
> > > Dear All,
> > > If ps mouse is not connected to the pc then it hangs the kbd.
> > > Can any one solve the problem?Thanks and Regds,
> >
> > This is not the fault of the Xserver.
> >
> > It is partly the fault of the archaic hardware design:
> > When you open the PS/2 mouse device without a mouse being connected the
> > chipset will generate a fault data byte after a long timeout period. Since
> > this data byte doesn't get serviced (appearantly no interrupt is generated)
> > the keyboard/mouse controller doesn't generate any interrupt for any
> > further events. If at all the kernel needs to handle this.
> >
> > The funny thing is: if you access the keyboard thru an ioctl (ie when
> > terminating X or by setting the keyboard rate) the fault package is
> > serviced and the keyboard starts working again.
> >
> > If at all this problem needs to be handled in the kernel.
> >
> > Egbert.
>
> So it seems that this bug should be reassigned to the Linux kernel. I'd be
> interested to know if those having problems are able to use gpm, or some
> other text-based, mouse-enabled programs without killing the keyboard.
This is a problem that I hit a while back in gpm, it is a simple one but
also one nearly impossible to deal with in X, only vaguely possible to
deal with in gpm.
Basicly it works like this, on some motherboards, with /some/ kernel
versions (I /believe/ it is no longer an issue with 2.4.20, probably
fixed a little before that, but someone who can reproduce this please
check), if there is no PS/2 mouse attached, and we attempt to write to
/dev/psaux, we lose.
The write blocks forever, even with non-blocking IO enabled, and the
keyboard is dead.
HOWEVER, if the program in question is killed and thus the device
closed, keyboard access remains.
How I solved this in gpm was straight forward enough, I set an alarm to
go off 5 seconds after each right, and when the write returns I cancel
it, if the write actually blocks then the alarm kills gpm and people get
the keyboard back.
Obviously, that same trick is really not much of an option for X.
Welcome to a hell that can only be fixed in the kernel. (=:]
Zephaniah E. Hull.
Debian gpm maintainer.
>
> Frank
--
1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.
Hey, if you've mlock'ed more than your available memory, there's nothing
the VM layer can do. Except maybe a nice printk("Kiss your *ss goodbye");
-- Linus
msg05279/pgp0.pgp
Description: PGP signature
Re: CVS X debs for sid.
On Thu, Dec 19, 2002 at 03:09:26AM +0900, ISHIKAWA Mutsumi wrote: > Patches sanity checks is disabled on this source. You may wish to lift my patch changes then. (With the exception of 09[23] and 908. 092 and 093 are evdev input patches which I have not sent upstream yet, you might of might not want them. 908 will be ready for taking for font exclusion tomorrow, right now it kills too much.) I did not do the arch specific ones because I can't test them, however they all apply cleanly, some of them without changes, er, did /not/ do the right thing. Zephaniah E. Hull. > But MANIFEST check is enabled. -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. "I am ecstatic that some moron re-invented a 1995 windows fuckup." -- Alan Cox pgp9yoYns3VGf.pgp Description: PGP signature
Re: CVS X debs for sid.
On Thu, Dec 19, 2002 at 02:20:39AM +0900, ISHIKAWA Mutsumi wrote: > Yet another XFree86 CVS .debs for sid on the apt line bellow: > > deb http://hanzubon.jp/HANZUBON/ hanzubon/$(ARCH)/ > deb http://hanzubon.jp/HANZUBON/ hanzubon/all/ > deb-src http://hanzubon.jp/HANZUBON/ hanzubon/source/ > > They are semi-automatic built every day (on i386) > > The are test to build on i386/alpha/powerpc/m68k/sparc/hppa/sh4 > and already success to build on i386/alpha/powerpc/m68k/hppa. Interesting, did you disable the various sanity checks on the patches and the manifest stuff, or go through and make it all work with them? I'm actually going back to readd some of the fonts either later today or tomorrow as it seems that some I removed as DFSG non-free are actually not copyrightable and are thus free. Zephaniah E. Hull. > > TODO: > bumped up version number. > > more, more and more cleanup > > cleanup source tar ball (tar balls are it still contains some non DFSG > fonts). > > cleaup patches > > some pending staff >- Is #100 PCI domain patch needed? current XFree86 CVS have PCI > domain support. >- Is #102 type6_kdb_xf86Events needed? It is already reported to > BTS. >- cleanup fonts.alias (#12 patch) > > on SPARC remove some unresolve vgaHW* function calls. > > update MANIFEST on other plat homes. -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. "Sir," barked one of those useless aristocratic generals to William Howard Russell, the great Times war correspondent, "I do not like what you write." "Then, sir," retorted Russell, "I suggest you do not do what I write about." pgprwvJKGpCKe.pgp Description: PGP signature
Re: CVS X debs for sid.
On Thu, Dec 19, 2002 at 03:09:26AM +0900, ISHIKAWA Mutsumi wrote: > Patches sanity checks is disabled on this source. You may wish to lift my patch changes then. (With the exception of 09[23] and 908. 092 and 093 are evdev input patches which I have not sent upstream yet, you might of might not want them. 908 will be ready for taking for font exclusion tomorrow, right now it kills too much.) I did not do the arch specific ones because I can't test them, however they all apply cleanly, some of them without changes, er, did /not/ do the right thing. Zephaniah E. Hull. > But MANIFEST check is enabled. -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. "I am ecstatic that some moron re-invented a 1995 windows fuckup." -- Alan Cox msg05054/pgp0.pgp Description: PGP signature
Re: CVS X debs for sid.
On Thu, Dec 19, 2002 at 02:20:39AM +0900, ISHIKAWA Mutsumi wrote: > Yet another XFree86 CVS .debs for sid on the apt line bellow: > > deb http://hanzubon.jp/HANZUBON/ hanzubon/$(ARCH)/ > deb http://hanzubon.jp/HANZUBON/ hanzubon/all/ > deb-src http://hanzubon.jp/HANZUBON/ hanzubon/source/ > > They are semi-automatic built every day (on i386) > > The are test to build on i386/alpha/powerpc/m68k/sparc/hppa/sh4 > and already success to build on i386/alpha/powerpc/m68k/hppa. Interesting, did you disable the various sanity checks on the patches and the manifest stuff, or go through and make it all work with them? I'm actually going back to readd some of the fonts either later today or tomorrow as it seems that some I removed as DFSG non-free are actually not copyrightable and are thus free. Zephaniah E. Hull. > > TODO: > bumped up version number. > > more, more and more cleanup > > cleanup source tar ball (tar balls are it still contains some non DFSG fonts). > > cleaup patches > > some pending staff >- Is #100 PCI domain patch needed? current XFree86 CVS have PCI > domain support. >- Is #102 type6_kdb_xf86Events needed? It is already reported to > BTS. >- cleanup fonts.alias (#12 patch) > > on SPARC remove some unresolve vgaHW* function calls. > > update MANIFEST on other plat homes. -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. "Sir," barked one of those useless aristocratic generals to William Howard Russell, the great Times war correspondent, "I do not like what you write." "Then, sir," retorted Russell, "I suggest you do not do what I write about." msg05052/pgp0.pgp Description: PGP signature
CVS X debs for sid.
First off, I'm going to say that these are i386 only, and that the sources will not build for other arches until someone gets all of the patches for said arch to apply against the CVS tree, updates the manifest files, and a few other things. Secondly I am going to stress that if you install these you WILL NOT file ANY bug reports on anything that so much as a ls on any X files, let alone on X itself or programs that run under X. (I have this thing about breathing, I like doing it, and if I survive this I know I would not survive if someone were to file bug reports with these installed.) Thirdly you should be aware that these are from X CVS, and are thus likely to be a bit unstable, you have been warned. Now, with that out of the way, on to the main event. YOU WILL NOT FILE ANY BUG REPORTS ABOUT SYSTEMS WITH THESE PACKAGES INSTALLED. deb http://people.debian.org/%7Ewarp/x_cvs/ ./ deb-src http://people.debian.org/%7Ewarp/x_cvs/ ./ YOU WILL NOT FILE ANY BUG REPORTS ABOUT SYSTEMS WITH THESE PACKAGES INSTALLED. These are clean replacements for all packages generated from the XFree86 source package. Several fonts that exist in the official debs are NOT in these for copyright reasons, see the bug about it and the post to -legal, hopefully either the copyrights will be straightened out and I will re-add them, or Branden will pull them from the official debs, I don't really care. If you are using these debs I would appreciate knowing about it. Zephaniah E. Hull. P.S.: YOU WILL NOT FILE ANY BUG REPORTS IF YOU HAVE THESE PACKAGES INSTALLED!!! -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. On Sat, 13 Jul 2002, Alexander Viro wrote: > > So I'd just do > > vi fs/dcache.c -c '/|= DCACHE_R/d|/nr_un/pu|<|x' > > and be done with that. Linus? Done. For future reference - don't anybody else try to send patches as vi scripts, please. Yes, it's manly, but let's face it, so is bungee-jumping with the cord tied to your testicles. Linus pgpRPUJ7WCb0M.pgp Description: PGP signature
CVS X debs for sid.
First off, I'm going to say that these are i386 only, and that the sources will not build for other arches until someone gets all of the patches for said arch to apply against the CVS tree, updates the manifest files, and a few other things. Secondly I am going to stress that if you install these you WILL NOT file ANY bug reports on anything that so much as a ls on any X files, let alone on X itself or programs that run under X. (I have this thing about breathing, I like doing it, and if I survive this I know I would not survive if someone were to file bug reports with these installed.) Thirdly you should be aware that these are from X CVS, and are thus likely to be a bit unstable, you have been warned. Now, with that out of the way, on to the main event. YOU WILL NOT FILE ANY BUG REPORTS ABOUT SYSTEMS WITH THESE PACKAGES INSTALLED. deb http://people.debian.org/%7Ewarp/x_cvs/ ./ deb-src http://people.debian.org/%7Ewarp/x_cvs/ ./ YOU WILL NOT FILE ANY BUG REPORTS ABOUT SYSTEMS WITH THESE PACKAGES INSTALLED. These are clean replacements for all packages generated from the XFree86 source package. Several fonts that exist in the official debs are NOT in these for copyright reasons, see the bug about it and the post to -legal, hopefully either the copyrights will be straightened out and I will re-add them, or Branden will pull them from the official debs, I don't really care. If you are using these debs I would appreciate knowing about it. Zephaniah E. Hull. P.S.: YOU WILL NOT FILE ANY BUG REPORTS IF YOU HAVE THESE PACKAGES INSTALLED!!! -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. On Sat, 13 Jul 2002, Alexander Viro wrote: > > So I'd just do > > vi fs/dcache.c -c '/|= DCACHE_R/d|/nr_un/pu|<|x' > > and be done with that. Linus? Done. For future reference - don't anybody else try to send patches as vi scripts, please. Yes, it's manly, but let's face it, so is bungee-jumping with the cord tied to your testicles. Linus msg05047/pgp0.pgp Description: PGP signature
Bug#173529: Two large groups of non-free fonts in main.
Severity: serious Package: xfonts-75dpi Note, while this is filed against xfonts-75dpi, it affects several of the font packages generated from the xfree86 source package, feel free to reassign to another package. The two large groups in question are the Utopia (UT*) and the Lucida (lu*) fonts. The only license I can find on the Utopia fonts is in the font files themselves: COPYRIGHT "Copyright (c) 1989, 1991 Adobe Systems Incorporated. All Rights Reserved." Obviously without something further we do not even have a license to distribute them, hopefully I am simply missing a license somewhere that gives us proper rights, however.. The license case for the Lucida fonts is a little more interesting. In the font files is the following notice: COMMENT (c) Copyright Bigelow & Holmes 1986, 1985. Lucida is a registered COMMENT trademark of Bigelow & Holmes. See LEGAL NOTICE file for terms COMMENT of the license. The contents of the file in question is below, what rights it gives is, a very interesting question. It does not explicitly give permission to modify, however it is vague enough that -legal should probably examine it. (Note, this is a /different/ license then the one Branden recently sent B&H a letter about.) This is the LEGAL NOTICE pertaining to the Lucida fonts from Bigelow & Holmes: NOTICE TO USER: The source code, including the glyphs or icons forming a par of the OPEN LOOK TM Graphic User Interface, on this tape and in these files is copyrighted under U.S. and international laws. Sun Microsystems, Inc. of Mountain View, California owns the copyright and has design patents pending on many of the icons. AT&T is the owner of the OPEN LOOK trademark associated with the materials on this tape. Users and possessors of this source code are hereby granted a nonexclusive, royalty-free copyright and design patent license to use this code in individual and commercial software. A royalty-free, nonexclusive trademark license to refer to the code and output as "OPEN LOOK" compatible is available from AT&T if, and only if, the appearance of the icons or glyphs is not changed in any manner except as absolutely necessary to accommodate the standard resolution of the screen or other output device, the code and output is not changed except as authorized herein, and the code and output is validated by AT&T. Bigelow & Holmes is the owner of the Lucida (R) trademark for the fonts and bit-mapped images associated with the materials on this tape. Users are granted a royalty-free, nonexclusive license to use the trademark only to identify the fonts and bit-mapped images if, and only if, the fonts and bit-mapped images are not modified in any way by the user. Any use of this source code must include, in the user documentation and internal comments to the code, notices to the end user as follows: (c) Copyright 1989 Sun Microsystems, Inc. Sun design patents pending in the U.S. and foreign countries. OPEN LOOK is a trademark of AT&T. Used by written permission of the owners. (c) Copyright Bigelow & Holmes 1986, 1985. Lucida is a registered trademark of Bigelow & Holmes. Permission to use the Lucida trademark is hereby granted only in association with the images and fonts described in this file. SUN MICROSYSTEMS, INC., AT&T, AND BIGELOW & HOLMES MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THIS SOURCE CODE FOR ANY PURPOSE. IT IS PROVIDED "AS IS" WITHOUT EXPRESS OR IMPLIED WARRANTY OF ANY KIND. SUN MICROSYSTEMS, INC., AT&T AND BIGELOW & HOLMES, SEVERALLY AND INDIVIDUALLY, DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOURCE CODE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL SUN MICROSYSTEMS, INC., AT&T OR BIGELOW & HOLMES BE LIABLE FOR ANY SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOURCE CODE. -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. Why blow away at a partition when you can chip away at it? I now present a script I just wrote that writes random bits of, well random bits, into random places in your favorite partition or file. For best (meaning most spectacular) results
Bug#173529: Two large groups of non-free fonts in main.
Severity: serious Package: xfonts-75dpi Note, while this is filed against xfonts-75dpi, it affects several of the font packages generated from the xfree86 source package, feel free to reassign to another package. The two large groups in question are the Utopia (UT*) and the Lucida (lu*) fonts. The only license I can find on the Utopia fonts is in the font files themselves: COPYRIGHT "Copyright (c) 1989, 1991 Adobe Systems Incorporated. All Rights Reserved." Obviously without something further we do not even have a license to distribute them, hopefully I am simply missing a license somewhere that gives us proper rights, however.. The license case for the Lucida fonts is a little more interesting. In the font files is the following notice: COMMENT (c) Copyright Bigelow & Holmes 1986, 1985. Lucida is a registered COMMENT trademark of Bigelow & Holmes. See LEGAL NOTICE file for terms COMMENT of the license. The contents of the file in question is below, what rights it gives is, a very interesting question. It does not explicitly give permission to modify, however it is vague enough that -legal should probably examine it. (Note, this is a /different/ license then the one Branden recently sent B&H a letter about.) This is the LEGAL NOTICE pertaining to the Lucida fonts from Bigelow & Holmes: NOTICE TO USER: The source code, including the glyphs or icons forming a par of the OPEN LOOK TM Graphic User Interface, on this tape and in these files is copyrighted under U.S. and international laws. Sun Microsystems, Inc. of Mountain View, California owns the copyright and has design patents pending on many of the icons. AT&T is the owner of the OPEN LOOK trademark associated with the materials on this tape. Users and possessors of this source code are hereby granted a nonexclusive, royalty-free copyright and design patent license to use this code in individual and commercial software. A royalty-free, nonexclusive trademark license to refer to the code and output as "OPEN LOOK" compatible is available from AT&T if, and only if, the appearance of the icons or glyphs is not changed in any manner except as absolutely necessary to accommodate the standard resolution of the screen or other output device, the code and output is not changed except as authorized herein, and the code and output is validated by AT&T. Bigelow & Holmes is the owner of the Lucida (R) trademark for the fonts and bit-mapped images associated with the materials on this tape. Users are granted a royalty-free, nonexclusive license to use the trademark only to identify the fonts and bit-mapped images if, and only if, the fonts and bit-mapped images are not modified in any way by the user. Any use of this source code must include, in the user documentation and internal comments to the code, notices to the end user as follows: (c) Copyright 1989 Sun Microsystems, Inc. Sun design patents pending in the U.S. and foreign countries. OPEN LOOK is a trademark of AT&T. Used by written permission of the owners. (c) Copyright Bigelow & Holmes 1986, 1985. Lucida is a registered trademark of Bigelow & Holmes. Permission to use the Lucida trademark is hereby granted only in association with the images and fonts described in this file. SUN MICROSYSTEMS, INC., AT&T, AND BIGELOW & HOLMES MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THIS SOURCE CODE FOR ANY PURPOSE. IT IS PROVIDED "AS IS" WITHOUT EXPRESS OR IMPLIED WARRANTY OF ANY KIND. SUN MICROSYSTEMS, INC., AT&T AND BIGELOW & HOLMES, SEVERALLY AND INDIVIDUALLY, DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOURCE CODE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL SUN MICROSYSTEMS, INC., AT&T OR BIGELOW & HOLMES BE LIABLE FOR ANY SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOURCE CODE. -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. Why blow away at a partition when you can chip away at it? I now present a script I just wrote that writes random bits of, well random bits, into random places in your favorite partition or file. For best (meaning most spectacular) results, u
Re: Question about X build tactics.
On Sun, Dec 15, 2002 at 05:56:16PM +0100, Michel D?nzer wrote: > On Son, 2002-12-15 at 16:28, Zephaniah E. Hull wrote: > > Is there a big reason why lndir is not used instead of cp in the build > > rules? > > > > For reasons of disk space alone something along the lines of: > > > > mkdir $(SOURCE_TREE) > > lndir ../../$(SOURCE_TREE)-real $(SOURCE_TREE)/ ifndef > > NOT_BUILDING_X_SERVER > > # create source tree for static, debuggable XFree86 server > > mkdir $(SOURCE_TREE)-xserver-xfree86-dbg > > lndir ../../$(SOURCE_TREE)-real $(SOURCE_TREE)-xserver-xfree86-dbg/ > > > > Seems reasonable, are there any catches that I am missing? > > I don't expect there to be, but if there are, cp -la should always work? After trying it, the lndir thing seems to work perfectly. It also saves over two hundred megs of disk space on the build target. (Which, admittedly, is only a drop in the bucket for a 1.4G build tree, however.) Zephaniah E. Hull. -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. "I would rather spend 10 hours reading someone else's source code than 10 minutes listening to Musak waiting for technical support which isn't." (By Dr. Greg Wettstein, Roger Maris Cancer Center) pgpSvwULJFksW.pgp Description: PGP signature
Re: Question about X build tactics.
On Sun, Dec 15, 2002 at 05:56:16PM +0100, Michel D?nzer wrote: > On Son, 2002-12-15 at 16:28, Zephaniah E. Hull wrote: > > Is there a big reason why lndir is not used instead of cp in the build > > rules? > > > > For reasons of disk space alone something along the lines of: > > > > mkdir $(SOURCE_TREE) > > lndir ../../$(SOURCE_TREE)-real $(SOURCE_TREE)/ ifndef >NOT_BUILDING_X_SERVER > > # create source tree for static, debuggable XFree86 server > > mkdir $(SOURCE_TREE)-xserver-xfree86-dbg > > lndir ../../$(SOURCE_TREE)-real $(SOURCE_TREE)-xserver-xfree86-dbg/ > > > > Seems reasonable, are there any catches that I am missing? > > I don't expect there to be, but if there are, cp -la should always work? After trying it, the lndir thing seems to work perfectly. It also saves over two hundred megs of disk space on the build target. (Which, admittedly, is only a drop in the bucket for a 1.4G build tree, however.) Zephaniah E. Hull. -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. "I would rather spend 10 hours reading someone else's source code than 10 minutes listening to Musak waiting for technical support which isn't." (By Dr. Greg Wettstein, Roger Maris Cancer Center) msg05030/pgp0.pgp Description: PGP signature
Question about X build tactics.
Is there a big reason why lndir is not used instead of cp in the build rules? For reasons of disk space alone something along the lines of: mkdir $(SOURCE_TREE) lndir ../../$(SOURCE_TREE)-real $(SOURCE_TREE)/ ifndef NOT_BUILDING_X_SERVER # create source tree for static, debuggable XFree86 server mkdir $(SOURCE_TREE)-xserver-xfree86-dbg lndir ../../$(SOURCE_TREE)-real $(SOURCE_TREE)-xserver-xfree86-dbg/ Seems reasonable, are there any catches that I am missing? (Aside from the minor bootstrapping problem as lndir is part of X.) Zephaniah E. Hull. (Finally done classifying the patches for use with CVS, then fixing all the ones that don't apply, now grumbling about disk space while trying to build .debs) -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. ALL programs are poems, it's just that not all programmers are poets. -- Jonathan Guthrie in the scary.devil.monastery pgpRaRx6YSKwn.pgp Description: PGP signature
Question about X build tactics.
Is there a big reason why lndir is not used instead of cp in the build rules? For reasons of disk space alone something along the lines of: mkdir $(SOURCE_TREE) lndir ../../$(SOURCE_TREE)-real $(SOURCE_TREE)/ ifndef NOT_BUILDING_X_SERVER # create source tree for static, debuggable XFree86 server mkdir $(SOURCE_TREE)-xserver-xfree86-dbg lndir ../../$(SOURCE_TREE)-real $(SOURCE_TREE)-xserver-xfree86-dbg/ Seems reasonable, are there any catches that I am missing? (Aside from the minor bootstrapping problem as lndir is part of X.) Zephaniah E. Hull. (Finally done classifying the patches for use with CVS, then fixing all the ones that don't apply, now grumbling about disk space while trying to build .debs) -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. ALL programs are poems, it's just that not all programmers are poets. -- Jonathan Guthrie in the scary.devil.monastery msg05026/pgp0.pgp Description: PGP signature
Bug#166550: [patch] X misparses the EXPS/2 mouse protocol.
On Sun, Oct 27, 2002 at 07:54:39PM -0500, [EMAIL PROTECTED] wrote: > On Sat, Oct 26, 2002 at 09:20:05PM -0400, Zephaniah E. Hull wrote: > > To make a long story short, X is wrong in how it parses the wheel data > > for EXPS/2 protocol mice. > > > > 0xF and 0x1 are used to indicate the first wheel, and 0xE and 0x2 for > > the second wheel. > > (Yes, I have real hardware which generates this.) > > Make the short story longer; specifically, I need to know for which mice > or mouse protocols this is going to generate spurious events, which you > mentioned would happen when you were talking to me about this on IRC. This is going to generate spurious events when speaking the EXPS/2 protocol from unpatched kernel HID layers, specificly drivers/input/mousedev.c generates the wheel data incorrectly, I have a patch for that which I'm trying to get accepted upstream. I have actual hardware which speaks the protocol in question, in both one and two wheel versions, and none actually generate anything except 0x1 and 0xf for the first wheel, the kernel will generate something other then that, if unpatched, for /very/ rapid wheel movements on slower systems. The problems of that with X and this patch are further reduced by the fact that ZAxisMapping will, if only given two buttons, map W axis (0x2 and 0xe) to the same buttons as the z axis, and if it is something other then those two it will be dropped. I do not expect to see anyone suddenly loosing functionality from this patch. (=:] Zephaniah E. Hull. -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. > Is there an API or other means to determine what video > card, namely the chipset, that the user has installed > on his machine? On a modern X86 machine use the PCI/AGP bus data. On a PS/2 use the MCA bus data. On nubus use the nubus probe data. On old style ISA bus PCs done a large pointy hat and spend several years reading arcane and forbidden scrolls -- Alan Cox pgpCtfy24Yz1h.pgp Description: PGP signature
Bug#166550: [patch] X misparses the EXPS/2 mouse protocol.
On Sun, Oct 27, 2002 at 07:54:39PM -0500, [EMAIL PROTECTED] wrote: > On Sat, Oct 26, 2002 at 09:20:05PM -0400, Zephaniah E. Hull wrote: > > To make a long story short, X is wrong in how it parses the wheel data > > for EXPS/2 protocol mice. > > > > 0xF and 0x1 are used to indicate the first wheel, and 0xE and 0x2 for > > the second wheel. > > (Yes, I have real hardware which generates this.) > > Make the short story longer; specifically, I need to know for which mice > or mouse protocols this is going to generate spurious events, which you > mentioned would happen when you were talking to me about this on IRC. This is going to generate spurious events when speaking the EXPS/2 protocol from unpatched kernel HID layers, specificly drivers/input/mousedev.c generates the wheel data incorrectly, I have a patch for that which I'm trying to get accepted upstream. I have actual hardware which speaks the protocol in question, in both one and two wheel versions, and none actually generate anything except 0x1 and 0xf for the first wheel, the kernel will generate something other then that, if unpatched, for /very/ rapid wheel movements on slower systems. The problems of that with X and this patch are further reduced by the fact that ZAxisMapping will, if only given two buttons, map W axis (0x2 and 0xe) to the same buttons as the z axis, and if it is something other then those two it will be dropped. I do not expect to see anyone suddenly loosing functionality from this patch. (=:] Zephaniah E. Hull. -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. > Is there an API or other means to determine what video > card, namely the chipset, that the user has installed > on his machine? On a modern X86 machine use the PCI/AGP bus data. On a PS/2 use the MCA bus data. On nubus use the nubus probe data. On old style ISA bus PCs done a large pointy hat and spend several years reading arcane and forbidden scrolls -- Alan Cox msg04422/pgp0.pgp Description: PGP signature
Bug#166550: [patch] X misparses the EXPS/2 mouse protocol.
Subject: [patch] X misparses the EXPS/2 mouse protocol.
Package: xserver-xfree86
Severity: normal
To make a long story short, X is wrong in how it parses the wheel data
for EXPS/2 protocol mice.
0xF and 0x1 are used to indicate the first wheel, and 0xE and 0x2 for
the second wheel.
(Yes, I have real hardware which generates this.)
diff -ur build-tree/xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c
build-tree.mine/xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c
--- xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c 2001-12-19
11:05:22.0 -0500
+++ xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c 2002-10-26
18:56:12.0 -0400
@@ -1423,7 +1423,12 @@
(pBuf[3] & 0x20) >> 1;/* button 5 */
dx = (pBuf[0] & 0x10) ?pBuf[1]-256 : pBuf[1];
dy = (pBuf[0] & 0x20) ? -(pBuf[2]-256) : -pBuf[2];
- dz = (pBuf[3] & 0x08) ? (pBuf[3] & 0x0f) - 16 : (pBuf[3] & 0x0f);
+ switch (pBuf[3] & 0x0F) {
+ case 0x01: dz = 1; break;
+ case 0x0f: dz = -1; break;
+ case 0x02: dw = 1; break;
+ case 0x0e: dw = -1; break;
+ }
break;
case PROT_MMPS2:/* MouseMan+ PS/2 */
--
1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.
It's also your right to f*ck up your own version of Linux, but you're
not getting close to mine.
Linus
pgpkGHbtq35EA.pgp
Description: PGP signature
Bug#166550: [patch] X misparses the EXPS/2 mouse protocol.
Subject: [patch] X misparses the EXPS/2 mouse protocol.
Package: xserver-xfree86
Severity: normal
To make a long story short, X is wrong in how it parses the wheel data
for EXPS/2 protocol mice.
0xF and 0x1 are used to indicate the first wheel, and 0xE and 0x2 for
the second wheel.
(Yes, I have real hardware which generates this.)
diff -ur build-tree/xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c
build-tree.mine/xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c
--- xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c 2001-12-19 11:05:22.0
-0500
+++ xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c 2002-10-26 18:56:12.0
+-0400
@@ -1423,7 +1423,12 @@
(pBuf[3] & 0x20) >> 1;/* button 5 */
dx = (pBuf[0] & 0x10) ?pBuf[1]-256 : pBuf[1];
dy = (pBuf[0] & 0x20) ? -(pBuf[2]-256) : -pBuf[2];
- dz = (pBuf[3] & 0x08) ? (pBuf[3] & 0x0f) - 16 : (pBuf[3] & 0x0f);
+ switch (pBuf[3] & 0x0F) {
+ case 0x01: dz = 1; break;
+ case 0x0f: dz = -1; break;
+ case 0x02: dw = 1; break;
+ case 0x0e: dw = -1; break;
+ }
break;
case PROT_MMPS2:/* MouseMan+ PS/2 */
--
1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.
It's also your right to f*ck up your own version of Linux, but you're
not getting close to mine.
Linus
msg04389/pgp0.pgp
Description: PGP signature
Re: gpm and X
On Mon, Oct 15, 2001 at 10:10:59PM +0200, Jens M?ller wrote:
> Since the upgrade to Debian Woody, my scroll wheel does not work any
> longer. I have "ms3" as gpm repeat type, and "Microsoft" as X mouse
> type. What is wrong here?
You want to use 'IntelliMouse' as the X mouse type, please ignore the
people saying to use raw.
Zephaniah E. Hull.
(Debian gpm maintainer.)
--
1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.
Having been the victim of forgeries myself, I sympathise. I've still got
my nutcraker handy for the day I identify and catch the scum...
-- Richard Gooch on l-k.
pgpeKxPFLcIYV.pgp
Description: PGP signature
Re: gpm and X
On Mon, Oct 15, 2001 at 10:10:59PM +0200, Jens M?ller wrote:
> Since the upgrade to Debian Woody, my scroll wheel does not work any
> longer. I have "ms3" as gpm repeat type, and "Microsoft" as X mouse
> type. What is wrong here?
You want to use 'IntelliMouse' as the X mouse type, please ignore the
people saying to use raw.
Zephaniah E. Hull.
(Debian gpm maintainer.)
--
1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.
Having been the victim of forgeries myself, I sympathise. I've still got
my nutcraker handy for the day I identify and catch the scum...
-- Richard Gooch on l-k.
msg03174/pgp0.pgp
Description: PGP signature
Re: ALERT: XFree86 4.1.0-3 maintainer scripts hosed; please wait for 4.1.0-4
On Fri, Aug 31, 2001 at 12:33:08AM -0600, Bruce Sass wrote: > and just in case it is not obvious (or too scary)... > > If you have sh linked to ash: > $ rm /bin/sh > $ ln -s /bin/bash /bin/sh > install, or whatever> > > ...is now working away to install the 58 broken packages I accumulated > over the last couple of upgrades. > > Branden, is there anyone who should not do the above? Yes, almost everyone. The proper command is 'dpkg --purge ash'. Zephaniah E. Hull. > > > - Bruce -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. > My kid brother tells me Visual Age for Java is the cat's pajamas I'm not a cat person, but I can just imagine the reaction of your average feline to someone's attempt to stuff it into a pair of pajamas. Now picture your hard disk after the thing installs. -- Berry Kercheval and Graham Reed on ASR. pgpvQPyXENxwe.pgp Description: PGP signature
Re: ALERT: XFree86 4.1.0-3 maintainer scripts hosed; please wait for 4.1.0-4
On Fri, Aug 31, 2001 at 12:33:08AM -0600, Bruce Sass wrote: > and just in case it is not obvious (or too scary)... > > If you have sh linked to ash: > $ rm /bin/sh > $ ln -s /bin/bash /bin/sh > install, or whatever> > > ...is now working away to install the 58 broken packages I accumulated > over the last couple of upgrades. > > Branden, is there anyone who should not do the above? Yes, almost everyone. The proper command is 'dpkg --purge ash'. Zephaniah E. Hull. > > > - Bruce -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. > My kid brother tells me Visual Age for Java is the cat's pajamas I'm not a cat person, but I can just imagine the reaction of your average feline to someone's attempt to stuff it into a pair of pajamas. Now picture your hard disk after the thing installs. -- Berry Kercheval and Graham Reed on ASR. PGP signature
Re: Issues with mouse and a suggested fix
On Sun, Aug 26, 2001 at 01:54:34AM +0200, Claes Andersson wrote: > Hello, > > X, gpm and wheel mouse is not a combination that works well together by > default in Debian. At least not when I installed it. This was the first > serious issue I had to deal with, and by looking at the debian-user archive > I can see that I am not alone. > > I struggled with this for a while and the solution for me was to change > gpm.conf to look like this: The proper config is this: > > type=imps2 > device=/dev/psaux repeat_type=ms3 > responsiveness= > append="" > > while at the same time making the relevant section in XF86Config-4 to look > like this: > >Protocol"IntelliMouse" >Device "/dev/gpmdata" > # For wheel mice >ZAxisMapping 4 5 >Buttons 5 > > The important part seems to be to set repeat type to raw in gpm. This way I > get the mouse to work both in console mode and in X, including the mouse > wheel. > > The protocol must of course be different between different mouses and the > gpm device will also have to change if the mouse is serial for example. > Apart from that, do you think that this is a sensible setting to have as > default? That is, gpm repeats "raw" to /dev/gpmdata? Also, will having > ZAxisMappings hurt a non-wheel mouse? The proper repeat type is ms3, with X reading in the IntelliMouse protocol, this should work in all cases. > > In that case, I found that gpm has different defaults than this in the > version of gpm I have (1.19.3), so I can file something on that. > However, I could not find out where XF86Config is created and what > defaults it has. Can anyone help? The X maintainer has been historicly unhelpful in trying to get the default sane for the X and gpm case. Zephaniah E. Hull. > > Claes > > _ > H?mta MSN Explorer kostnadsfritt p? http://explorer.msn.se > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. Don't Snoop... ...the government hates competition. If the government wants us to respect the law, it should set a better example. -- Steve B ([EMAIL PROTECTED]) on /. pgpztvlcrDpU3.pgp Description: PGP signature
Re: Issues with mouse and a suggested fix
On Sun, Aug 26, 2001 at 01:54:34AM +0200, Claes Andersson wrote: > Hello, > > X, gpm and wheel mouse is not a combination that works well together by > default in Debian. At least not when I installed it. This was the first > serious issue I had to deal with, and by looking at the debian-user archive > I can see that I am not alone. > > I struggled with this for a while and the solution for me was to change > gpm.conf to look like this: The proper config is this: > > type=imps2 > device=/dev/psaux repeat_type=ms3 > responsiveness= > append="" > > while at the same time making the relevant section in XF86Config-4 to look > like this: > >Protocol"IntelliMouse" >Device "/dev/gpmdata" > # For wheel mice >ZAxisMapping 4 5 >Buttons 5 > > The important part seems to be to set repeat type to raw in gpm. This way I > get the mouse to work both in console mode and in X, including the mouse > wheel. > > The protocol must of course be different between different mouses and the > gpm device will also have to change if the mouse is serial for example. > Apart from that, do you think that this is a sensible setting to have as > default? That is, gpm repeats "raw" to /dev/gpmdata? Also, will having > ZAxisMappings hurt a non-wheel mouse? The proper repeat type is ms3, with X reading in the IntelliMouse protocol, this should work in all cases. > > In that case, I found that gpm has different defaults than this in the > version of gpm I have (1.19.3), so I can file something on that. > However, I could not find out where XF86Config is created and what > defaults it has. Can anyone help? The X maintainer has been historicly unhelpful in trying to get the default sane for the X and gpm case. Zephaniah E. Hull. > > Claes > > _ > H?mta MSN Explorer kostnadsfritt p? http://explorer.msn.se > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. Don't Snoop... ...the government hates competition. If the government wants us to respect the law, it should set a better example. -- Steve B ([EMAIL PROTECTED]) on /. PGP signature
Re: 4.1.0 tdfx bugs
On Sat, Jul 21, 2001 at 04:59:09PM -0700, Ian Eure wrote: > i'm seeing two minor, but irritating bugs with xfree86 4.1.0-0pre1v5. > > 1. switching from x to a text console corrupts fonts. very minor, but the > lower half of all my exclamation points are missing. :) This seems to be semi-random, and switching to X and then back will fix it, or sometimes move it to a different set of chars, I'm trying to figure out what is going on there between other things. > > 2. switching from x to a text console and back to x breaks the middle > mouse button. when i press the middle mouse button, it registers as the > right button. only way to fix this is to reboot, and not use a text > console. That is, odd, are you using GPM? Is the mouse serial? PS2? USB? Specifics of your setup would be useful. Zephaniah E. Hull. > > i have an asus p5a-b mobo (ali chipset) with a k6-3 500, 320mb ram, a > voodoo3 2000 agp 16mb video board, and a logitech mouseman serial mouse on > linux 2.4.7. > > everything else is great (except my wacom graphire _still_ won't work with > the driver distributed with xfree86 4.1.0. grr.), keep up the good > work. :) -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. You don't have to be crazy to be a member of the project, but you will be.. <=:] ^^^ was that a ref to debian or qf? I forget. => knghtbrd: QF you sure? * knghtbrd was thinking maybe it was both It applies to both, but I was talking about QF at the time.. ahh, okie. pgplQGLQRFwkI.pgp Description: PGP signature
Re: 4.1.0 tdfx bugs
On Sat, Jul 21, 2001 at 04:59:09PM -0700, Ian Eure wrote: > i'm seeing two minor, but irritating bugs with xfree86 4.1.0-0pre1v5. > > 1. switching from x to a text console corrupts fonts. very minor, but the > lower half of all my exclamation points are missing. :) This seems to be semi-random, and switching to X and then back will fix it, or sometimes move it to a different set of chars, I'm trying to figure out what is going on there between other things. > > 2. switching from x to a text console and back to x breaks the middle > mouse button. when i press the middle mouse button, it registers as the > right button. only way to fix this is to reboot, and not use a text > console. That is, odd, are you using GPM? Is the mouse serial? PS2? USB? Specifics of your setup would be useful. Zephaniah E. Hull. > > i have an asus p5a-b mobo (ali chipset) with a k6-3 500, 320mb ram, a > voodoo3 2000 agp 16mb video board, and a logitech mouseman serial mouse on > linux 2.4.7. > > everything else is great (except my wacom graphire _still_ won't work with > the driver distributed with xfree86 4.1.0. grr.), keep up the good > work. :) -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. You don't have to be crazy to be a member of the project, but you will be.. <=:] ^^^ was that a ref to debian or qf? I forget. => knghtbrd: QF you sure? * knghtbrd was thinking maybe it was both It applies to both, but I was talking about QF at the time.. ahh, okie. PGP signature
Re: Is HW accel for DRI possible with Voodoo3 PCI and sid debs?
On Mon, Apr 09, 2001 at 09:47:56AM -0500, Branden Robinson wrote: > On Mon, Apr 09, 2001 at 08:33:42AM -0500, Thomas E. Vaughan wrote: > > I don't see any dri/drm errors in my X server output, but 3D stuff is not > > hardware-accelerated. > > I'm not positive, but this might depend on the long-awaited PCI GART > implementation. One of the 3D heads on this list may be able to clarify. Sometime in the next week I'll get the crash box finished and I'll throw in the V3 and verify, however you should not need an AGP V3, however you will need the kernel DRM module. (Which will pull in the AGP stuff even though it is not needed.) Zephaniah E. Hull. > > -- > G. Branden Robinson | > Debian GNU/Linux| If God had intended for man to go about > [EMAIL PROTECTED] | naked, we would have been born that way. > http://www.debian.org/~branden/ | -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Guns don't kill people. It's those damn bullets. Guns just make them go really really fast." -- Jake Johanson pgpmzgcvlsSfl.pgp Description: PGP signature
Re: Is HW accel for DRI possible with Voodoo3 PCI and sid debs?
On Mon, Apr 09, 2001 at 09:47:56AM -0500, Branden Robinson wrote: > On Mon, Apr 09, 2001 at 08:33:42AM -0500, Thomas E. Vaughan wrote: > > I don't see any dri/drm errors in my X server output, but 3D stuff is not > > hardware-accelerated. > > I'm not positive, but this might depend on the long-awaited PCI GART > implementation. One of the 3D heads on this list may be able to clarify. Sometime in the next week I'll get the crash box finished and I'll throw in the V3 and verify, however you should not need an AGP V3, however you will need the kernel DRM module. (Which will pull in the AGP stuff even though it is not needed.) Zephaniah E. Hull. > > -- > G. Branden Robinson | > Debian GNU/Linux| If God had intended for man to go about > [EMAIL PROTECTED] | naked, we would have been born that way. > http://www.debian.org/~branden/ | -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Guns don't kill people. It's those damn bullets. Guns just make them go really really fast." -- Jake Johanson PGP signature
Re: Testing/mesademos
On Sat, Apr 07, 2001 at 12:38:18PM -0700, Jon Pennington wrote: > On Sat, Apr 07, 2001 at 10:26:13AM +0200, Marcelo E. Magallon wrote: > > >> Jon Pennington <[EMAIL PROTECTED]> writes: > > > > > Absolutely! This is what I meant to say. > > > > Oh, sorry, I missunderstood. > > It looked that way :) > > > > Shipping the mesademos package in binary form does not make any > > > sense. There are too many libGL implementations floating around for > > > that. > > > > Actually, this is a tempting reason to ship them as binaries. The > > program *can not* fail with "undefined symbol foobar". If it does, > > either the program is badly broken or the OpenGL implementation used to > > compile it is even more broken. But no, I'm not going to do this for > > this reason. > > Like Zeph said, though, the packages are most useful in source > *because* you can use different libGL implementations to compile them. > As I understand it (and I'm probably wrong), libGL implementations > vary in the DRI project from one family of drivers to the next. > Shipping binaries simply isn't a good idea the way I see it. (I smoke > a lot of crack, though, so don't quote me) Errm, a GL program compiled against /any/ libGL should work with any other libGL, if this is not the case then something is VERY broken. Of course, in this respect, the nVidia libGL is severely broken shit in the respect that if you compile a program against it you can't use that program with any other libGL, however those are not in Debian so we don't have to worry about it. (=:] Zephaniah E. Hull. > > -- > -=|JP|=-"This space intentionally left blank." > Jon Pennington | Debian 2.4 -o) > [EMAIL PROTECTED] | Auto Enthusiast/\\ > Kansas City, MO, USA| Proud Husband and Father _\_V > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Microsoft is a cross between the Borg and the Ferengi. Unfortunately, they use Borg to do their marketing and Ferengi to do their programming." -- Simon Slavin in asr pgptK7KLj3SdS.pgp Description: PGP signature
Re: Testing/mesademos
On Sat, Apr 07, 2001 at 12:38:18PM -0700, Jon Pennington wrote: > On Sat, Apr 07, 2001 at 10:26:13AM +0200, Marcelo E. Magallon wrote: > > >> Jon Pennington <[EMAIL PROTECTED]> writes: > > > > > Absolutely! This is what I meant to say. > > > > Oh, sorry, I missunderstood. > > It looked that way :) > > > > Shipping the mesademos package in binary form does not make any > > > sense. There are too many libGL implementations floating around for > > > that. > > > > Actually, this is a tempting reason to ship them as binaries. The > > program *can not* fail with "undefined symbol foobar". If it does, > > either the program is badly broken or the OpenGL implementation used to > > compile it is even more broken. But no, I'm not going to do this for > > this reason. > > Like Zeph said, though, the packages are most useful in source > *because* you can use different libGL implementations to compile them. > As I understand it (and I'm probably wrong), libGL implementations > vary in the DRI project from one family of drivers to the next. > Shipping binaries simply isn't a good idea the way I see it. (I smoke > a lot of crack, though, so don't quote me) Errm, a GL program compiled against /any/ libGL should work with any other libGL, if this is not the case then something is VERY broken. Of course, in this respect, the nVidia libGL is severely broken shit in the respect that if you compile a program against it you can't use that program with any other libGL, however those are not in Debian so we don't have to worry about it. (=:] Zephaniah E. Hull. > > -- > -=|JP|=-"This space intentionally left blank." > Jon Pennington | Debian 2.4 -o) > [EMAIL PROTECTED] | Auto Enthusiast/\\ > Kansas City, MO, USA| Proud Husband and Father _\_V > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Microsoft is a cross between the Borg and the Ferengi. Unfortunately, they use Borg to do their marketing and Ferengi to do their programming." -- Simon Slavin in asr PGP signature
Re: Testing/mesademos
On Sat, Apr 07, 2001 at 10:26:13AM +0200, Marcelo E. Magallon wrote: > >> Jon Pennington <[EMAIL PROTECTED]> writes: > > Shipping the mesademos package in binary form does not make any > > sense. There are too many libGL implementations floating around for > > that. > > Actually, this is a tempting reason to ship them as binaries. The > program *can not* fail with "undefined symbol foobar". If it does, > either the program is badly broken or the OpenGL implementation used to > compile it is even more broken. But no, I'm not going to do this for > this reason. A better reason would be because they are very handy for debugging and benchmarking the OpenGL implementations. For instance gears is a /very/ standard benchmark, and one of the first things I like people to run if they are having problems with the DRI drivers. Zephaniah E. Hull. > > -- > Marcelo -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Seen on the back of a T-Shirt: "I am a bomb technician. If you see me running, try to keep up." pgpKY7QES64kK.pgp Description: PGP signature
Re: Testing/mesademos
On Sat, Apr 07, 2001 at 10:26:13AM +0200, Marcelo E. Magallon wrote: > >> Jon Pennington <[EMAIL PROTECTED]> writes: > > Shipping the mesademos package in binary form does not make any > > sense. There are too many libGL implementations floating around for > > that. > > Actually, this is a tempting reason to ship them as binaries. The > program *can not* fail with "undefined symbol foobar". If it does, > either the program is badly broken or the OpenGL implementation used to > compile it is even more broken. But no, I'm not going to do this for > this reason. A better reason would be because they are very handy for debugging and benchmarking the OpenGL implementations. For instance gears is a /very/ standard benchmark, and one of the first things I like people to run if they are having problems with the DRI drivers. Zephaniah E. Hull. > > -- > Marcelo -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Seen on the back of a T-Shirt: "I am a bomb technician. If you see me running, try to keep up." PGP signature
Re: new aptable cvs dri fails with mga
On Wed, Mar 28, 2001 at 02:03:32PM -0500, Stuart Ballard wrote: > "Thomas E. Vaughan" wrote: > > > > Maybe I failed to do something that I was supposed to do, but dri is > > disabled for me. > > > > DRM version = 2.0.1, expected 3.0.x > > DRI disabled. > > What kernel are you using? Also, did you add the lines to your /etc/X11/XF86Config-4 and restart X? > > Sounds like you have outdated drm modules in your kernel. Zephaniah's > previous message claims that 2.4.2 has adequate modules. If you are > using an older kernel, you may need to build the drm modules yourself or > upgrade your kernel. If you are using 2.4.2... perhaps the packages > actually do need to include the drm modules. I'll like do that as soon as the modules have been updated to work with the current 2.4.3-pre kernels. (Solid lock otherwise.) Zephaniah E. Hull. > > Stuart. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Knghtbrd: Eww, find a better name, the movie sucked.. Mercury: The engine is better than the movie pgpGiQsZ94Apz.pgp Description: PGP signature
Re: new aptable cvs dri fails with mga
On Wed, Mar 28, 2001 at 02:03:32PM -0500, Stuart Ballard wrote: > "Thomas E. Vaughan" wrote: > > > > Maybe I failed to do something that I was supposed to do, but dri is > > disabled for me. > > > > DRM version = 2.0.1, expected 3.0.x > > DRI disabled. > > What kernel are you using? Also, did you add the lines to your /etc/X11/XF86Config-4 and restart X? > > Sounds like you have outdated drm modules in your kernel. Zephaniah's > previous message claims that 2.4.2 has adequate modules. If you are > using an older kernel, you may need to build the drm modules yourself or > upgrade your kernel. If you are using 2.4.2... perhaps the packages > actually do need to include the drm modules. I'll like do that as soon as the modules have been updated to work with the current 2.4.3-pre kernels. (Solid lock otherwise.) Zephaniah E. Hull. > > Stuart. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Knghtbrd: Eww, find a better name, the movie sucked.. Mercury: The engine is better than the movie PGP signature
APT-able Debian DRI CVS packages ready for testing.
Yes, thats right, it is now apt-able. Aside from not having kernel modules yet, there are no known packaging issues. Same warnings from the previous message apply. The URL is http://people.debian.org/~warp/dri/. For APT throw the following two lines into your /etc/apt/sources.list. deb http://people.debian.org/~warp/dri/ ./ deb-src http://people.debian.org/~warp/dri/ ./ Please send me reports on if it works, possible issues, etc. Zephaniah E. Hull. -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "And now, little kittens, we're going to run across red-hot motherboards, with our bare feet." -- Buzh. pgp3lZBBe2NRk.pgp Description: PGP signature
APT-able Debian DRI CVS packages ready for testing.
Yes, thats right, it is now apt-able. Aside from not having kernel modules yet, there are no known packaging issues. Same warnings from the previous message apply. The URL is http://people.debian.org/~warp/dri/. For APT throw the following two lines into your /etc/apt/sources.list. deb http://people.debian.org/~warp/dri/ ./ deb-src http://people.debian.org/~warp/dri/ ./ Please send me reports on if it works, possible issues, etc. Zephaniah E. Hull. -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "And now, little kittens, we're going to run across red-hot motherboards, with our bare feet." -- Buzh. PGP signature
Re: [Dri-devel] Re: Debian DRI CVS packages ready for testing.
On Tue, Mar 27, 2001 at 01:53:13PM +0100, Jules Bean wrote: > On Tue, Mar 27, 2001 at 02:51:14PM +0200, Michel D?nzer wrote: > > Alan Hourihane wrote: > > > > > > On Tue, Mar 27, 2001 at 02:33:19PM +0200, Michel D?nzer wrote: > > > > Jules Bean wrote: > > > > > > > > > [EMAIL PROTECTED] [17] LIBGL_DEBUG=1 glxinfo > > > > > libGL error: dlopen failed: /usr/X11R6/lib/modules/dri/tdfx_dri.so: > > > > > cannot open shared object file: No such file or directory > > > > > libGL error: dlopen failed: /usr/X11R6/lib/modules/dri/tdfx_dri.so: > > > > > cannot open shared object file: No such file or directory > > > > > display: :0.0 screen:0 > > > > > direct rendering: No > > > > > > > > > > A working workaround for me is to ln -s /usr/X11R6/lib/modules/dri to > > > > > ../modules-dri/dri. It looks like the ModulePath things aren't doing > > > > > their job: > > > > > > > > [snip] > > > > > > > > Indeed, the ModulePaths only affect the X server, the clients > > > > (libGL.so.1.2 to be precise) look for *_dri.so in > > > > $(ProjectRoot)/lib/modules/dri/ . I guess they should be moved there. > > > > > > > Indeed, but from the code, you should be able to set > > > > > > LIBGL_DRIVERS_PATH > > > > > > to point to your *_dri.so files. > > > > Yeah, another workaround. :) > > > > I just realized that the modules are probably moved from the correct > > location > > to the wrong one in debian/rules so that just has to be modified such that > > only the driver modules get moved to .../modules-dri/drivers/ . If I wasn't > > at > > work right now I'd include a patch. > > Or, if there's a reason not to want to pollute the modules directory > which belongs to Branden's packages, libGL could presumably be patched > to look in the new location? That I believe is the correct answer for now, I'm about to fly out the door, but when I get back I'll fix that, the ldconfig problem, move things to people.debian.org, and see about making it apt-able. Thanks a lot for the testing and debugging, most of the problems were of the sort which pop up when you've been up nearly 24 hours working on something. (=:] Zephaniah E. Hull. > > Jules > -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. >OK, fine. You're arguing semantics, though. "arguing semantics" is not the same as "arguing nomenclature". My DI was very good at arguing semantics. He had this funny idea that an "unloaded" weapon was one that you had personally inspected and that the semantic difference mattered. Something about not wanting to do the paperwork of one of us killed someone with an unloaded weapon. Most technical debates are ultimately about semantics, but that doesn't mean that they are unimportant. -- Shmuel Metz and Steve Sobol on ASR. pgp6eZOJB6Kyr.pgp Description: PGP signature
Re: [Dri-devel] Re: Debian DRI CVS packages ready for testing.
On Tue, Mar 27, 2001 at 01:53:13PM +0100, Jules Bean wrote: > On Tue, Mar 27, 2001 at 02:51:14PM +0200, Michel D?nzer wrote: > > Alan Hourihane wrote: > > > > > > On Tue, Mar 27, 2001 at 02:33:19PM +0200, Michel D?nzer wrote: > > > > Jules Bean wrote: > > > > > > > > > jules@pear [17] LIBGL_DEBUG=1 glxinfo > > > > > libGL error: dlopen failed: /usr/X11R6/lib/modules/dri/tdfx_dri.so: > > > > > cannot open shared object file: No such file or directory > > > > > libGL error: dlopen failed: /usr/X11R6/lib/modules/dri/tdfx_dri.so: > > > > > cannot open shared object file: No such file or directory > > > > > display: :0.0 screen:0 > > > > > direct rendering: No > > > > > > > > > > A working workaround for me is to ln -s /usr/X11R6/lib/modules/dri to > > > > > ../modules-dri/dri. It looks like the ModulePath things aren't doing > > > > > their job: > > > > > > > > [snip] > > > > > > > > Indeed, the ModulePaths only affect the X server, the clients > > > > (libGL.so.1.2 to be precise) look for *_dri.so in > > > > $(ProjectRoot)/lib/modules/dri/ . I guess they should be moved there. > > > > > > > Indeed, but from the code, you should be able to set > > > > > > LIBGL_DRIVERS_PATH > > > > > > to point to your *_dri.so files. > > > > Yeah, another workaround. :) > > > > I just realized that the modules are probably moved from the correct location > > to the wrong one in debian/rules so that just has to be modified such that > > only the driver modules get moved to .../modules-dri/drivers/ . If I wasn't at > > work right now I'd include a patch. > > Or, if there's a reason not to want to pollute the modules directory > which belongs to Branden's packages, libGL could presumably be patched > to look in the new location? That I believe is the correct answer for now, I'm about to fly out the door, but when I get back I'll fix that, the ldconfig problem, move things to people.debian.org, and see about making it apt-able. Thanks a lot for the testing and debugging, most of the problems were of the sort which pop up when you've been up nearly 24 hours working on something. (=:] Zephaniah E. Hull. > > Jules > -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. >OK, fine. You're arguing semantics, though. "arguing semantics" is not the same as "arguing nomenclature". My DI was very good at arguing semantics. He had this funny idea that an "unloaded" weapon was one that you had personally inspected and that the semantic difference mattered. Something about not wanting to do the paperwork of one of us killed someone with an unloaded weapon. Most technical debates are ultimately about semantics, but that doesn't mean that they are unimportant. -- Shmuel Metz and Steve Sobol on ASR. PGP signature
Re: Debian DRI CVS packages ready for testing.
On Mon, Mar 26, 2001 at 10:11:57PM -0700, Jason Gunthorpe wrote: > > On Mon, 26 Mar 2001, Zephaniah E. Hull wrote: > > > The subject says most of it, the packages are at > > http://master.debian.org/~warp/, they are /not/ apt-able right now, I'll > > sort that out tomorrow. > > Did you miss the memo that this sort of thing should be on klecker and > referenced through people.debian.org? Memo? We have memos? When did we get memos? And who should I shoot? (=:] Wow, yes, I think it is safe to say that I have missed any and all memos, I'll move it tomorrow? Zephaniah E. Hull. > > Jason -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. ALL programs are poems, it's just that not all programmers are poets. -- Jonathan Guthrie in the scary.devil.monastery pgpJcSGeHCOXp.pgp Description: PGP signature
Debian DRI CVS packages ready for testing.
The subject says most of it, the packages are at http://master.debian.org/~warp/, they are /not/ apt-able right now, I'll sort that out tomorrow. They are still very much in testing, follow the depends on the packages, and, err, you may have to do an ldconfig after installing xlibmesa3-dri, I forgot that in the postinst and I'm going to sleep now, again, I'll deal with it tomorrow. The packages are against current unstable, and seem to work for me. Please do NOT build debian packages with these packages installed at this time, also please report all packaging issues to me, if you're not sure a bug is purely in the DRI code also report it to me. Note that this does NOT include the kernel DRM modules, the ones in 2.4.2+ seem to work with the current DRI CVS, and thus these packages. Once I have a few more things pounded out I will likely have a cron job build them every 24 hours, eventually these packages will likely go into unstable, though likely only being built once or twice a week at that point. Zephaniah E. Hull. (Debian developer, certifiabley insane.) -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "I am ecstatic that some moron re-invented a 1995 windows fuckup." -- Alan Cox pgpA6q8ewRrv8.pgp Description: PGP signature
Re: Debian DRI CVS packages ready for testing.
On Mon, Mar 26, 2001 at 10:11:57PM -0700, Jason Gunthorpe wrote: > > On Mon, 26 Mar 2001, Zephaniah E. Hull wrote: > > > The subject says most of it, the packages are at > > http://master.debian.org/~warp/, they are /not/ apt-able right now, I'll > > sort that out tomorrow. > > Did you miss the memo that this sort of thing should be on klecker and > referenced through people.debian.org? Memo? We have memos? When did we get memos? And who should I shoot? (=:] Wow, yes, I think it is safe to say that I have missed any and all memos, I'll move it tomorrow? Zephaniah E. Hull. > > Jason -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. ALL programs are poems, it's just that not all programmers are poets. -- Jonathan Guthrie in the scary.devil.monastery PGP signature
Debian DRI CVS packages ready for testing.
The subject says most of it, the packages are at http://master.debian.org/~warp/, they are /not/ apt-able right now, I'll sort that out tomorrow. They are still very much in testing, follow the depends on the packages, and, err, you may have to do an ldconfig after installing xlibmesa3-dri, I forgot that in the postinst and I'm going to sleep now, again, I'll deal with it tomorrow. The packages are against current unstable, and seem to work for me. Please do NOT build debian packages with these packages installed at this time, also please report all packaging issues to me, if you're not sure a bug is purely in the DRI code also report it to me. Note that this does NOT include the kernel DRM modules, the ones in 2.4.2+ seem to work with the current DRI CVS, and thus these packages. Once I have a few more things pounded out I will likely have a cron job build them every 24 hours, eventually these packages will likely go into unstable, though likely only being built once or twice a week at that point. Zephaniah E. Hull. (Debian developer, certifiabley insane.) -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "I am ecstatic that some moron re-invented a 1995 windows fuckup." -- Alan Cox PGP signature
Re: Update on status of CVS DRI packages.
On Mon, Mar 26, 2001 at 02:08:53PM -0500, Branden Robinson wrote: > On Mon, Mar 26, 2001 at 01:58:00PM -0500, Zephaniah E. Hull wrote: > > After much prodding and poking I have it down to three issues, the > > naming scheme is as follows, with the issues below. > > > > xlibmesa3-dri contains libGL, libGLU, and libGLw, it also contains > > usr/X11R6/lib/modules.dri/dri/(gamma|i810|mga|r128|radeon|sis|tdfx)_driso. > > I don't think GLw is supposed to be available as a shared object. Whoops, my mistake, it is as a .a in -dev and not at all in xlibmesa3-dri. > > > xlibmesa-dri-dev contains the devel files for xlibmesa3-dri. > > > > xlibosmesa3-dri contains libOSMesa. > > > > xlibosmesa-dri-dev contains the devel files for xlibosmesa3-dri. > > Do you have any feedback for Marcelo Magallon, who, IIRC claims you don't > need to provide versions of these? I'll probably stop building them before I put things up. > > > xserver-dri contains usr/X11R6/bin/XFree86.dri and more contents for > > /usr/X11R6/lib/modules.dri. > > > > This scheme removes all need for diversions, leaving with exactly three > > issues before I can produce .debs for people to test. > > Okay, great. > > > 1: I'd really like Branden to agree to the naming scheme. > > One tweak. I think the package names should be exactly as my X package > names, with "-dri" appended. Even for the -dev packages. > > So, e.g., xlibmesa-dev-dri. Sounds reasonable. > > Also, for the sake of sheer symmetry I don't see why you can't use the > pathnames XFree86-dri and modules-dri. Done. > > > 2: Until Branden packages 4.0.3 or later I need to provide the > > XFree86.dri, and need to figure out the proper way to set > > /etc/X11/Xserver XFree86.dri. > > (Branden, can you point this out please? It should be simple.) > > Actually, it probably isn't. You need to do something akin to a > global-search and replace in debconf template names in the templates, > config, and other maintainer scripts, replacing "xserver-xfree86" with > "xserver-xfree86-dri". > > Also, you need to be sure that all references to "/usr/.../XFree86" in > these files change to "XFree86-dri". Ugh, I was hoping to avoid most of that as the dri xserver package depends on yours. (See below.) > > > 3: The XF86Config-4 needs to have two lines[1] added so X will search > > the modules.dri directory then the modules directory, I'll probably > > leave this up to the user for now. > > Yes, let's do that. Otherwise I have to hack dexconf. You can use my > message() shell function in the postinst to tell the user to do this. > > > As soon as those three have been addressed I'll put .debs up somewhere > > aptable for people to test. > > > > Zephaniah E. Hull. > > > > 1: > > ModulePath "/usr/X11R6/lib/modules.dri" > > ModulePath "/usr/X11R6/lib/modules" > > Are you sure both are needed? Your xserver-xfree86-dri package should > provide a superset of the modules that my xserver-xfree86 package does. Actually it is a subset, providing only what is used by the DRI code and leaving the rest to your packages, otherwise I would simply conflict with xserver-xfree86. The reason is two fold, the first is that it is roughly what the DRI project is providing in other forms. The second is that the DRI cvs tree does not include everything that the X cvs tree does, trying to provide a superset would be quite a bit more work all around. Zephaniah E. Hull. > > -- > G. Branden Robinson |"To be is to do" -- Plato > Debian GNU/Linux|"To do is to be" -- Aristotle > [EMAIL PROTECTED] |"Do be do be do" -- Sinatra > http://www.debian.org/~branden/ | -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. I am an "expert". Fear me, for I will wreak untold damage upon anything I can get my grubby hands on. -- Matt McLeod on ASR. pgpmyvhkyO4sz.pgp Description: PGP signature
Update on status of CVS DRI packages.
After much prodding and poking I have it down to three issues, the naming scheme is as follows, with the issues below. xlibmesa3-dri contains libGL, libGLU, and libGLw, it also contains usr/X11R6/lib/modules.dri/dri/(gamma|i810|mga|r128|radeon|sis|tdfx)_dri.so. xlibmesa-dri-dev contains the devel files for xlibmesa3-dri. xlibosmesa3-dri contains libOSMesa. xlibosmesa-dri-dev contains the devel files for xlibosmesa3-dri. xserver-dri contains usr/X11R6/bin/XFree86.dri and more contents for /usr/X11R6/lib/modules.dri. This scheme removes all need for diversions, leaving with exactly three issues before I can produce .debs for people to test. 1: I'd really like Branden to agree to the naming scheme. 2: Until Branden packages 4.0.3 or later I need to provide the XFree86.dri, and need to figure out the proper way to set /etc/X11/Xserver XFree86.dri. (Branden, can you point this out please? It should be simple.) 3: The XF86Config-4 needs to have two lines[1] added so X will search the modules.dri directory then the modules directory, I'll probably leave this up to the user for now. As soon as those three have been addressed I'll put .debs up somewhere aptable for people to test. Zephaniah E. Hull. 1: ModulePath "/usr/X11R6/lib/modules.dri" ModulePath "/usr/X11R6/lib/modules" -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Seen on the back of a T-Shirt: "I am a bomb technician. If you see me running, try to keep up." pgpNDwiPbQHvc.pgp Description: PGP signature
Re: Update on status of CVS DRI packages.
On Mon, Mar 26, 2001 at 02:08:53PM -0500, Branden Robinson wrote: > On Mon, Mar 26, 2001 at 01:58:00PM -0500, Zephaniah E. Hull wrote: > > After much prodding and poking I have it down to three issues, the > > naming scheme is as follows, with the issues below. > > > > xlibmesa3-dri contains libGL, libGLU, and libGLw, it also contains > > usr/X11R6/lib/modules.dri/dri/(gamma|i810|mga|r128|radeon|sis|tdfx)_driso. > > I don't think GLw is supposed to be available as a shared object. Whoops, my mistake, it is as a .a in -dev and not at all in xlibmesa3-dri. > > > xlibmesa-dri-dev contains the devel files for xlibmesa3-dri. > > > > xlibosmesa3-dri contains libOSMesa. > > > > xlibosmesa-dri-dev contains the devel files for xlibosmesa3-dri. > > Do you have any feedback for Marcelo Magallon, who, IIRC claims you don't > need to provide versions of these? I'll probably stop building them before I put things up. > > > xserver-dri contains usr/X11R6/bin/XFree86.dri and more contents for > > /usr/X11R6/lib/modules.dri. > > > > This scheme removes all need for diversions, leaving with exactly three > > issues before I can produce .debs for people to test. > > Okay, great. > > > 1: I'd really like Branden to agree to the naming scheme. > > One tweak. I think the package names should be exactly as my X package > names, with "-dri" appended. Even for the -dev packages. > > So, e.g., xlibmesa-dev-dri. Sounds reasonable. > > Also, for the sake of sheer symmetry I don't see why you can't use the > pathnames XFree86-dri and modules-dri. Done. > > > 2: Until Branden packages 4.0.3 or later I need to provide the > > XFree86.dri, and need to figure out the proper way to set > > /etc/X11/Xserver XFree86.dri. > > (Branden, can you point this out please? It should be simple.) > > Actually, it probably isn't. You need to do something akin to a > global-search and replace in debconf template names in the templates, > config, and other maintainer scripts, replacing "xserver-xfree86" with > "xserver-xfree86-dri". > > Also, you need to be sure that all references to "/usr/.../XFree86" in > these files change to "XFree86-dri". Ugh, I was hoping to avoid most of that as the dri xserver package depends on yours. (See below.) > > > 3: The XF86Config-4 needs to have two lines[1] added so X will search > > the modules.dri directory then the modules directory, I'll probably > > leave this up to the user for now. > > Yes, let's do that. Otherwise I have to hack dexconf. You can use my > message() shell function in the postinst to tell the user to do this. > > > As soon as those three have been addressed I'll put .debs up somewhere > > aptable for people to test. > > > > Zephaniah E. Hull. > > > > 1: > > ModulePath "/usr/X11R6/lib/modules.dri" > > ModulePath "/usr/X11R6/lib/modules" > > Are you sure both are needed? Your xserver-xfree86-dri package should > provide a superset of the modules that my xserver-xfree86 package does. Actually it is a subset, providing only what is used by the DRI code and leaving the rest to your packages, otherwise I would simply conflict with xserver-xfree86. The reason is two fold, the first is that it is roughly what the DRI project is providing in other forms. The second is that the DRI cvs tree does not include everything that the X cvs tree does, trying to provide a superset would be quite a bit more work all around. Zephaniah E. Hull. > > -- > G. Branden Robinson |"To be is to do" -- Plato > Debian GNU/Linux|"To do is to be" -- Aristotle > [EMAIL PROTECTED] |"Do be do be do" -- Sinatra > http://www.debian.org/~branden/ | -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. I am an "expert". Fear me, for I will wreak untold damage upon anything I can get my grubby hands on. -- Matt McLeod on ASR. PGP signature
Update on status of CVS DRI packages.
After much prodding and poking I have it down to three issues, the naming scheme is as follows, with the issues below. xlibmesa3-dri contains libGL, libGLU, and libGLw, it also contains usr/X11R6/lib/modules.dri/dri/(gamma|i810|mga|r128|radeon|sis|tdfx)_dri.so. xlibmesa-dri-dev contains the devel files for xlibmesa3-dri. xlibosmesa3-dri contains libOSMesa. xlibosmesa-dri-dev contains the devel files for xlibosmesa3-dri. xserver-dri contains usr/X11R6/bin/XFree86.dri and more contents for /usr/X11R6/lib/modules.dri. This scheme removes all need for diversions, leaving with exactly three issues before I can produce .debs for people to test. 1: I'd really like Branden to agree to the naming scheme. 2: Until Branden packages 4.0.3 or later I need to provide the XFree86.dri, and need to figure out the proper way to set /etc/X11/Xserver XFree86.dri. (Branden, can you point this out please? It should be simple.) 3: The XF86Config-4 needs to have two lines[1] added so X will search the modules.dri directory then the modules directory, I'll probably leave this up to the user for now. As soon as those three have been addressed I'll put .debs up somewhere aptable for people to test. Zephaniah E. Hull. 1: ModulePath "/usr/X11R6/lib/modules.dri" ModulePath "/usr/X11R6/lib/modules" -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Seen on the back of a T-Shirt: "I am a bomb technician. If you see me running, try to keep up." PGP signature
Re: CVS DRI packages.
On Sat, Mar 24, 2001 at 11:14:20PM -0500, Branden Robinson wrote: > On Sat, Mar 24, 2001 at 09:00:51PM -0500, Zephaniah E. Hull wrote: > > The 4 mesa packages are obvious, they will conflict, provide, and > > replace their counterparts[1]. > > > > Now, xserver-dri is a little less obvious, it depends on > > xserver-xfree86, but also needs to override 14 files[2] from it. > > I see superscripts but no footnotes. See my reply to Marcelo E. Magallon for said footnotes. Also, what he pointed out for the X server should work, not sure why I did not remember that. Zephaniah E. Hull. > > -- > G. Branden Robinson |Never underestimate the power of human > Debian GNU/Linux|stupidity. > [EMAIL PROTECTED] |-- Robert Heinlein > http://www.debian.org/~branden/ | -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Knghtbrd: Any suggestions on how to semi-easily make $55? Mercury: if you went and beat the crap out of some QL people I'm sure you'd get at least tenfold that from people expressing their gratitude ;> (my luck he takes that seriously hehe) Knghtbrd: This channel is logged.. [msg(Knghtbrd)] If you can provide transportation.. <=:] [Knghtbrd([EMAIL PROTECTED])] hahahaha pgpBggOOTJA4I.pgp Description: PGP signature
Re: CVS DRI packages.
On Sun, Mar 25, 2001 at 05:15:09AM +0200, Marcelo E. Magallon wrote: > I'm sorry, I forgot one important bit. > > >> "Zephaniah E. Hull" <[EMAIL PROTECTED]> writes: > > > My rough naming scheme is as follows: xlibmesa3-dri, xlibmesa-dri-dev, > > xlibosmesa3-dri, xlibosmesa-dri-dev, and xserver-dri. > > You might want to provide > xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel (or whatever > the actual path is), as every now and then the DRM modules in the > kernel get out of sync with the ones in CVS. That will be after I get the basics working, likely provided in the same manner as other sets of kernel models. Zephaniah E. Hull. > > -- > Marcelo -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. It's also your right to f*ck up your own version of Linux, but you're not getting close to mine. Linus pgpUVxig8K3Qj.pgp Description: PGP signature
Re: CVS DRI packages.
On Sun, Mar 25, 2001 at 05:10:47AM +0200, Marcelo E. Magallon wrote: > >> "Zephaniah E. Hull" <[EMAIL PROTECTED]> writes: > > > My rough naming scheme is as follows: xlibmesa3-dri, xlibmesa-dri-dev, > > xlibosmesa3-dri, xlibosmesa-dri-dev, and xserver-dri. > > I would drop the xlibosmesa packages. libOSMesa is a software only > client side off-screen rendering library. > > > The 4 mesa packages are obvious, they will conflict, provide, and > > replace their counterparts[1]. > > You forgot the footnotes. Ahh, yes, my mistake. 1: Just s/-dri//g to get their counterparts. 2: I'll append the list to the bottom of this message. > > > Right now I'm undecided on how to do the override, calling dpkg-divert > > from the preinst and postrm would work, but seems to be more of a kludge. > > Is there other way? I actually think it's safer that way. Using alternatives might work, but Branden would have to very explicitly support that. It might be possible to get X to search a different module path first, but all examples of that turn out to be very ugly in the config file, I'll keep poking. Hopefully Branden will have some ideas. Zephaniah E. Hull. > > -- > Marcelo usr/X11R6/bin/XFree86 usr/X11R6/lib/modules/drivers/ati_drv.o usr/X11R6/lib/modules/drivers/atimisc_drv.o usr/X11R6/lib/modules/drivers/glint_drv.o usr/X11R6/lib/modules/drivers/i810_drv.o usr/X11R6/lib/modules/drivers/mga_drv.o usr/X11R6/lib/modules/drivers/r128_drv.o usr/X11R6/lib/modules/drivers/radeon_drv.o usr/X11R6/lib/modules/drivers/tdfx_drv.o usr/X11R6/lib/modules/drivers/vga_drv.o usr/X11R6/lib/modules/extensions/libGLcore.a usr/X11R6/lib/modules/extensions/libdri.a usr/X11R6/lib/modules/extensions/libglx.a usr/X11R6/lib/modules/linux/libdrm.a -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. ``Who killed the server at the colo site?'' ``Weasel killed the server at the colo site'' ``Not me'' ``Then who?'' ``m2 killed the server at the colo site'' ... pgpwUoS2QGZjN.pgp Description: PGP signature
Re: CVS DRI packages.
On Sat, Mar 24, 2001 at 11:14:20PM -0500, Branden Robinson wrote: > On Sat, Mar 24, 2001 at 09:00:51PM -0500, Zephaniah E. Hull wrote: > > The 4 mesa packages are obvious, they will conflict, provide, and > > replace their counterparts[1]. > > > > Now, xserver-dri is a little less obvious, it depends on > > xserver-xfree86, but also needs to override 14 files[2] from it. > > I see superscripts but no footnotes. See my reply to Marcelo E. Magallon for said footnotes. Also, what he pointed out for the X server should work, not sure why I did not remember that. Zephaniah E. Hull. > > -- > G. Branden Robinson |Never underestimate the power of human > Debian GNU/Linux|stupidity. > [EMAIL PROTECTED] |-- Robert Heinlein > http://www.debian.org/~branden/ | -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Knghtbrd: Any suggestions on how to semi-easily make $55? Mercury: if you went and beat the crap out of some QL people I'm sure you'd get at least tenfold that from people expressing their gratitude ;> (my luck he takes that seriously hehe) Knghtbrd: This channel is logged.. [msg(Knghtbrd)] If you can provide transportation.. <=:] [Knghtbrd([EMAIL PROTECTED])] hahahaha PGP signature
CVS DRI packages.
I am currently about ready to start testing of .debs out of the DRI cvs tree. I have a rough naming scheme, and a list of exactly what files will to be overridden. My rough naming scheme is as follows: xlibmesa3-dri, xlibmesa-dri-dev, xlibosmesa3-dri, xlibosmesa-dri-dev, and xserver-dri. The 4 mesa packages are obvious, they will conflict, provide, and replace their counterparts[1]. Now, xserver-dri is a little less obvious, it depends on xserver-xfree86, but also needs to override 14 files[2] from it. Right now I'm undecided on how to do the override, calling dpkg-divert from the preinst and postrm would work, but seems to be more of a kludge. As soon as the name scheme is agreed on and we have figured out how to override those files I can start testing on the DRI packages. Zephaniah E. Hull. -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Microsoft is a cross between the Borg and the Ferengi. Unfortunately, they use Borg to do their marketing and Ferengi to do their programming." -- Simon Slavin in asr pgpZ7nCAARj7R.pgp Description: PGP signature
Re: CVS DRI packages.
On Sun, Mar 25, 2001 at 05:15:09AM +0200, Marcelo E. Magallon wrote: > I'm sorry, I forgot one important bit. > > >> "Zephaniah E. Hull" <[EMAIL PROTECTED]> writes: > > > My rough naming scheme is as follows: xlibmesa3-dri, xlibmesa-dri-dev, > > xlibosmesa3-dri, xlibosmesa-dri-dev, and xserver-dri. > > You might want to provide > xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel (or whatever > the actual path is), as every now and then the DRM modules in the > kernel get out of sync with the ones in CVS. That will be after I get the basics working, likely provided in the same manner as other sets of kernel models. Zephaniah E. Hull. > > -- > Marcelo -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. It's also your right to f*ck up your own version of Linux, but you're not getting close to mine. Linus PGP signature
Re: CVS DRI packages.
On Sun, Mar 25, 2001 at 05:10:47AM +0200, Marcelo E. Magallon wrote: > >> "Zephaniah E. Hull" <[EMAIL PROTECTED]> writes: > > > My rough naming scheme is as follows: xlibmesa3-dri, xlibmesa-dri-dev, > > xlibosmesa3-dri, xlibosmesa-dri-dev, and xserver-dri. > > I would drop the xlibosmesa packages. libOSMesa is a software only > client side off-screen rendering library. > > > The 4 mesa packages are obvious, they will conflict, provide, and > > replace their counterparts[1]. > > You forgot the footnotes. Ahh, yes, my mistake. 1: Just s/-dri//g to get their counterparts. 2: I'll append the list to the bottom of this message. > > > Right now I'm undecided on how to do the override, calling dpkg-divert > > from the preinst and postrm would work, but seems to be more of a kludge. > > Is there other way? I actually think it's safer that way. Using alternatives might work, but Branden would have to very explicitly support that. It might be possible to get X to search a different module path first, but all examples of that turn out to be very ugly in the config file, I'll keep poking. Hopefully Branden will have some ideas. Zephaniah E. Hull. > > -- > Marcelo usr/X11R6/bin/XFree86 usr/X11R6/lib/modules/drivers/ati_drv.o usr/X11R6/lib/modules/drivers/atimisc_drv.o usr/X11R6/lib/modules/drivers/glint_drv.o usr/X11R6/lib/modules/drivers/i810_drv.o usr/X11R6/lib/modules/drivers/mga_drv.o usr/X11R6/lib/modules/drivers/r128_drv.o usr/X11R6/lib/modules/drivers/radeon_drv.o usr/X11R6/lib/modules/drivers/tdfx_drv.o usr/X11R6/lib/modules/drivers/vga_drv.o usr/X11R6/lib/modules/extensions/libGLcore.a usr/X11R6/lib/modules/extensions/libdri.a usr/X11R6/lib/modules/extensions/libglx.a usr/X11R6/lib/modules/linux/libdrm.a -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. ``Who killed the server at the colo site?'' ``Weasel killed the server at the colo site'' ``Not me'' ``Then who?'' ``m2 killed the server at the colo site'' ... PGP signature
CVS DRI packages.
I am currently about ready to start testing of .debs out of the DRI cvs tree. I have a rough naming scheme, and a list of exactly what files will to be overridden. My rough naming scheme is as follows: xlibmesa3-dri, xlibmesa-dri-dev, xlibosmesa3-dri, xlibosmesa-dri-dev, and xserver-dri. The 4 mesa packages are obvious, they will conflict, provide, and replace their counterparts[1]. Now, xserver-dri is a little less obvious, it depends on xserver-xfree86, but also needs to override 14 files[2] from it. Right now I'm undecided on how to do the override, calling dpkg-divert from the preinst and postrm would work, but seems to be more of a kludge. As soon as the name scheme is agreed on and we have figured out how to override those files I can start testing on the DRI packages. Zephaniah E. Hull. -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Microsoft is a cross between the Borg and the Ferengi. Unfortunately, they use Borg to do their marketing and Ferengi to do their programming." -- Simon Slavin in asr PGP signature
Re: Help needed, TDFX [Re: Release-critical Bugreport for March 23, 2001]
On Sat, Mar 24, 2001 at 03:20:09PM -0500, Branden Robinson wrote: > On Sat, Mar 24, 2001 at 02:48:23PM -0500, Zephaniah E. Hull wrote: > > X4 no longer knows about glide2 > > That's not precisely true. xfree86 Build-Depends on libglide2-dev for a > reason; to build the "glide" driver which gives you a *2D* X environment on > Voodoo Graphics and Voodoo2 cards. More accurately, I should have said the X4 tdfx driver no longer knows anything about glide2. Sadly, it is very likely non-trivial to get the tdfx driver working with both glide2 and DRI source wise, let alone run time. Zephaniah E. Hull. > > -- > G. Branden Robinson |It was a typical net.exercise -- a > Debian GNU/Linux|screaming mob pounding on a greasy spot > [EMAIL PROTECTED] |on the pavement, where used to lie the > http://www.debian.org/~branden/ |carcass of a dead horse. -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. >OK, fine. You're arguing semantics, though. "arguing semantics" is not the same as "arguing nomenclature". My DI was very good at arguing semantics. He had this funny idea that an "unloaded" weapon was one that you had personally inspected and that the semantic difference mattered. Something about not wanting to do the paperwork of one of us killed someone with an unloaded weapon. Most technical debates are ultimately about semantics, but that doesn't mean that they are unimportant. -- Shmuel Metz and Steve Sobol on ASR. pgp9KvnAc4dIa.pgp Description: PGP signature
Re: Help needed, TDFX [Re: Release-critical Bugreport for March 23, 2001]
On Sat, Mar 24, 2001 at 08:08:16PM +0100, Marcelo E. Magallon wrote: > >> Joseph Carter <[EMAIL PROTECTED]> writes: > > > Neither. It's that the X server and Glide2 would have to cooperate in > > order to let you do it. As of XFree4, X no longer knows how to talk to > > Glide2, but does know how to talk to Glide3. Evil, eh? > > Then why does it work for V1 and V2? > > What you are saying sound like "there's no DRM for glide2". > > Maybe the bit of info I'm missing is why would I want to use glide2 > instead of glide3 if I have a V3? I remember vaguely something along > the lines of "all the V3s are equal, but some are more equal than > others". Maybe I should go and buy myself a V1 or V2... Ok, the design of the V3 chip is that if you try to talk to it about 3D while it is in the middle of doing 2D, or try to talk to it about 2D while it is doing 3D then you will have serious problems. (FWIW, almost all 2D/3D cards have the same.) Thus the 2D code must know that you are doing 3D on the card, X3 knew about glide2, and worked with it to avoid these problems. X4 no longer knows about glide2, it knows about the DRI, which means that trying to use mesa3-glide2 on a V3 with X4 will result in a disaster. You can use a V1 and V2 just fine with it under X4 because X4 does not need to know anything about them, they are purely 3D cards which just pass-through the VGA signal normally, this is why they don't natively do 3D in a window. I suppose it might be worth looking at the tdfx driver to see if I can get it to know about glide2 again, as last I looked mesa3-glide2 + X3 was faster then DRI + X4 on the V3 (though, this may change with the DRI CVS code, which I should have packaged soon.). Any questions? Zephaniah E. Hull. (Just waking up, so not as clear as I could be, sorry.) > > -- > Marcelo -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. }>No. I just point out to troublemakers that I have an English degree, }>which means that I am allowed to make changes to the English language. }>(What _else_ could it possibly be for?) }Wow; in that case, my physics degree is *WAY* more useful than I }had thought. This just proves how useless a computer science degree is: there is hardly any useful science involved at all. I want my computer black magic degree! -- Victoria Swann, Jonathan Dursi, and D. Joseph Creighton on ASR pgpCSJk3ssXcm.pgp Description: PGP signature
Re: Help needed, TDFX [Re: Release-critical Bugreport for March 23, 2001]
On Sat, Mar 24, 2001 at 03:20:09PM -0500, Branden Robinson wrote: > On Sat, Mar 24, 2001 at 02:48:23PM -0500, Zephaniah E. Hull wrote: > > X4 no longer knows about glide2 > > That's not precisely true. xfree86 Build-Depends on libglide2-dev for a > reason; to build the "glide" driver which gives you a *2D* X environment on > Voodoo Graphics and Voodoo2 cards. More accurately, I should have said the X4 tdfx driver no longer knows anything about glide2. Sadly, it is very likely non-trivial to get the tdfx driver working with both glide2 and DRI source wise, let alone run time. Zephaniah E. Hull. > > -- > G. Branden Robinson |It was a typical net.exercise -- a > Debian GNU/Linux|screaming mob pounding on a greasy spot > [EMAIL PROTECTED] |on the pavement, where used to lie the > http://www.debian.org/~branden/ |carcass of a dead horse. -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. >OK, fine. You're arguing semantics, though. "arguing semantics" is not the same as "arguing nomenclature". My DI was very good at arguing semantics. He had this funny idea that an "unloaded" weapon was one that you had personally inspected and that the semantic difference mattered. Something about not wanting to do the paperwork of one of us killed someone with an unloaded weapon. Most technical debates are ultimately about semantics, but that doesn't mean that they are unimportant. -- Shmuel Metz and Steve Sobol on ASR. PGP signature
Re: Help needed, TDFX [Re: Release-critical Bugreport for March 23, 2001]
On Sat, Mar 24, 2001 at 08:08:16PM +0100, Marcelo E. Magallon wrote: > >> Joseph Carter <[EMAIL PROTECTED]> writes: > > > Neither. It's that the X server and Glide2 would have to cooperate in > > order to let you do it. As of XFree4, X no longer knows how to talk to > > Glide2, but does know how to talk to Glide3. Evil, eh? > > Then why does it work for V1 and V2? > > What you are saying sound like "there's no DRM for glide2". > > Maybe the bit of info I'm missing is why would I want to use glide2 > instead of glide3 if I have a V3? I remember vaguely something along > the lines of "all the V3s are equal, but some are more equal than > others". Maybe I should go and buy myself a V1 or V2... Ok, the design of the V3 chip is that if you try to talk to it about 3D while it is in the middle of doing 2D, or try to talk to it about 2D while it is doing 3D then you will have serious problems. (FWIW, almost all 2D/3D cards have the same.) Thus the 2D code must know that you are doing 3D on the card, X3 knew about glide2, and worked with it to avoid these problems. X4 no longer knows about glide2, it knows about the DRI, which means that trying to use mesa3-glide2 on a V3 with X4 will result in a disaster. You can use a V1 and V2 just fine with it under X4 because X4 does not need to know anything about them, they are purely 3D cards which just pass-through the VGA signal normally, this is why they don't natively do 3D in a window. I suppose it might be worth looking at the tdfx driver to see if I can get it to know about glide2 again, as last I looked mesa3-glide2 + X3 was faster then DRI + X4 on the V3 (though, this may change with the DRI CVS code, which I should have packaged soon.). Any questions? Zephaniah E. Hull. (Just waking up, so not as clear as I could be, sorry.) > > -- > Marcelo -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. }>No. I just point out to troublemakers that I have an English degree, }>which means that I am allowed to make changes to the English language. }>(What _else_ could it possibly be for?) }Wow; in that case, my physics degree is *WAY* more useful than I }had thought. This just proves how useless a computer science degree is: there is hardly any useful science involved at all. I want my computer black magic degree! -- Victoria Swann, Jonathan Dursi, and D. Joseph Creighton on ASR PGP signature
Re: Help needed, TDFX [Re: Release-critical Bugreport for March 23, 2001]
On Fri, Mar 23, 2001 at 11:29:12PM +0100, Marcelo E. Magallon wrote: > >> BugScan reporter <[EMAIL PROTECTED]> writes: > > > Package: mesag3-glide2 (debian/main) > > Maintainer: Marcelo E. Magallon <[EMAIL PROTECTED]> > > 74471 Open GL xscreensavers cause X to hang with 3DFX cards. > > I need help with this bug, I can't test this as I don't have TDFX > hardware. The big question is which X server was he running. You simply CAN NOT use mesag3-glide2 on a V3 with X4, it won't work. However a simple conflicts won't work, because you CAN use mesag3-glide2 for a V1 or a V2 with X4, though glide for the V1 is still broken in sid. (It is an upstream issue, I hope to have time to mess with it soon though.) Zephaniah E. Hull. (The glide maintainer.) > > -- > Marcelo -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. > My kid brother tells me Visual Age for Java is the cat's pajamas I'm not a cat person, but I can just imagine the reaction of your average feline to someone's attempt to stuff it into a pair of pajamas. Now picture your hard disk after the thing installs. -- Berry Kercheval and Graham Reed on ASR. pgpY13YQdPqAM.pgp Description: PGP signature
Re: ctrl-alt-F11
On Sun, Jan 07, 2001 at 01:11:00AM +0100, Christian T. Steigies wrote: > Hi, > On my i386 box I run two X servers, one on vt9 (24-bit) and one on vt10 > (16-bit). From time to time I press the wrong function key when changeing > servers, like ctrl-alt-F11. ctrl-alt-F11 immediately causes the machine to > completely lockup, clocks stop, can't kill the X server, even the MagicSysRQ > key does not work anymore, can not log in via the network. Is this exspected > behaviour or did I manage to configure something wrong? This is really not all that surprising, what video card is it? Zephaniah E. Hull. > > Christian. -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Pshaw! *I* am a paid-up member of the Mystic Order of Arachnid Vigilance." "Please. Why don't you go fight evil somewhere else? I'm trying to sleep here." -- Rodger Donaldson and Eric The Read in alt.sysadmin.recovery pgpPouhFRQ45a.pgp Description: PGP signature
Re: ctrl-alt-F11
On Sun, Jan 07, 2001 at 01:11:00AM +0100, Christian T. Steigies wrote: > Hi, > On my i386 box I run two X servers, one on vt9 (24-bit) and one on vt10 > (16-bit). From time to time I press the wrong function key when changeing > servers, like ctrl-alt-F11. ctrl-alt-F11 immediately causes the machine to > completely lockup, clocks stop, can't kill the X server, even the MagicSysRQ > key does not work anymore, can not log in via the network. Is this exspected > behaviour or did I manage to configure something wrong? This is really not all that surprising, what video card is it? Zephaniah E. Hull. > > Christian. -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Pshaw! *I* am a paid-up member of the Mystic Order of Arachnid Vigilance." "Please. Why don't you go fight evil somewhere else? I'm trying to sleep here." -- Rodger Donaldson and Eric The Read in alt.sysadmin.recovery PGP signature
Re: -11 gives graphics corruption with V3 3000
On Tue, Dec 12, 2000 at 10:39:55PM +, Matthew Garrett wrote: > xserver-xfree86-11 gives corruption on my V3 3000. Black bars run across > the top of the screen, and moving windows causes corruption. I'm running at > 1792x1344 using DRI. Dropping back to the xserver-10 package (and keeping > the -11 ones for everything else) fixed things. Does -11 have a new > upstream version? Errr, it actually WORKS at 1792x1344? *grumble* Try it at 1024x768, it may be the same bug, or a different one. Zephaniah E. Hull. (About to start filing severity important bugs against X, with patches.) > > -- > Matthew Garrett | [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. ALL programs are poems, it's just that not all programmers are poets. -- Jonathan Guthrie in the scary.devil.monastery pgpdWr4wfX1d5.pgp Description: PGP signature
Re: -11 gives graphics corruption with V3 3000
On Tue, Dec 12, 2000 at 10:39:55PM +, Matthew Garrett wrote: > xserver-xfree86-11 gives corruption on my V3 3000. Black bars run across > the top of the screen, and moving windows causes corruption. I'm running at > 1792x1344 using DRI. Dropping back to the xserver-10 package (and keeping > the -11 ones for everything else) fixed things. Does -11 have a new > upstream version? Errr, it actually WORKS at 1792x1344? *grumble* Try it at 1024x768, it may be the same bug, or a different one. Zephaniah E. Hull. (About to start filing severity important bugs against X, with patches.) > > -- > Matthew Garrett | [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. ALL programs are poems, it's just that not all programmers are poets. -- Jonathan Guthrie in the scary.devil.monastery PGP signature
Re: modules for the X 4.x server
On Wed, Nov 29, 2000 at 09:53:52PM -0800, Seth Arnold wrote: > God only knows what int10 It is used for 'softbooting' video cards, basicly reiniting. Very likely used for your second head. > and record Hell if I know. > does. I also probably don't need > some of these (actually, glx/dri doesn't work in my current dual-head > setup, so removing those might actually help! :) Err, you probably want to remove them, every now and then there are, issues, with the DRI code trees. Zephaniah E. Hull. > -- but what the hey, > it mostly works great. :) > > -- > ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all > really impressed down here, I can tell you.'' -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Guns don't kill people. It's those damn bullets. Guns just make them go really really fast." -- Jake Johanson pgpvMqEq63DP3.pgp Description: PGP signature
Re: modules for the X 4.x server
On Wed, Nov 29, 2000 at 09:53:52PM -0800, Seth Arnold wrote: > God only knows what int10 It is used for 'softbooting' video cards, basicly reiniting. Very likely used for your second head. > and record Hell if I know. > does. I also probably don't need > some of these (actually, glx/dri doesn't work in my current dual-head > setup, so removing those might actually help! :) Err, you probably want to remove them, every now and then there are, issues, with the DRI code trees. Zephaniah E. Hull. > -- but what the hey, > it mostly works great. :) > > -- > ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all > really impressed down here, I can tell you.'' -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Guns don't kill people. It's those damn bullets. Guns just make them go really really fast." -- Jake Johanson PGP signature
Re: XFree86 4.0.1 architecture status
On Sun, Nov 26, 2000 at 04:17:36AM -0500, Christopher C. Chimelis wrote: > I'm going to lean on the glide maintainer a bit to test out the 64-bit > sources for glide on a 32-bit platform to see if they work (other > volunteers are welcome since he hasn't gotten back to me in awhile). > If they do, we can probably enable DRI support for 3Dfx cards as well > (which would be another first for a dist on Alpha). Great work on the > packaging end to make this all possible. I talked to Joseph Kain about this, and there is chance that the 64-bit branch may actually be folded into trunk, however I'll do the merge myself very soon. However, my current goal is to figure out what the hell is going on with the sst1 driver. Zephaniah E. Hull. > > > Alpha also needs to build the xfree86v3 source package. It is the > > only arch other than i386 that needs to do so. > > Ok, I'll work on that tomorrow. > > C -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. I still do not understand why manglement believes that cutting off the oxygen flow to the brain will INCREASE productivity. The reason they made that decision is probably because they couldn't think clearly due to wearing neckties. -- Paul Tomko on ASR. pgpBjQNWRM5J2.pgp Description: PGP signature
Re: XFree86 4.0.1 architecture status
On Sun, Nov 26, 2000 at 04:17:36AM -0500, Christopher C. Chimelis wrote: > I'm going to lean on the glide maintainer a bit to test out the 64-bit > sources for glide on a 32-bit platform to see if they work (other > volunteers are welcome since he hasn't gotten back to me in awhile). > If they do, we can probably enable DRI support for 3Dfx cards as well > (which would be another first for a dist on Alpha). Great work on the > packaging end to make this all possible. I talked to Joseph Kain about this, and there is chance that the 64-bit branch may actually be folded into trunk, however I'll do the merge myself very soon. However, my current goal is to figure out what the hell is going on with the sst1 driver. Zephaniah E. Hull. > > > Alpha also needs to build the xfree86v3 source package. It is the > > only arch other than i386 that needs to do so. > > Ok, I'll work on that tomorrow. > > C -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. I still do not understand why manglement believes that cutting off the oxygen flow to the brain will INCREASE productivity. The reason they made that decision is probably because they couldn't think clearly due to wearing neckties. -- Paul Tomko on ASR. PGP signature
Re: [nveber@primusolutions.net: DGA problems in 4.0.1]
Please don't send mail directly to Branden. For the DGA stuff, X4 uses DGA V2, X3 uses DGA V1, that is probably why you are having this problem. Zephaniah E. Hull. -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Here's your cable. We made it fifty feet long, just in case. In case what, in case tectonic movement makes the serial ports farther apart? -- Carl Jacobs on ASR. pgpx4IQpY35X2.pgp Description: PGP signature
Re: [nveber@primusolutions.net: DGA problems in 4.0.1]
Please don't send mail directly to Branden. For the DGA stuff, X4 uses DGA V2, X3 uses DGA V1, that is probably why you are having this problem. Zephaniah E. Hull. -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Here's your cable. We made it fifty feet long, just in case. In case what, in case tectonic movement makes the serial ports farther apart? -- Carl Jacobs on ASR. PGP signature
Re: [tomlins@cam.org: DRI wth 2.2.18pre kernels]
Please don't send mail to Branden directly, questions such as this are much better suited for debian-x. > - Forwarded message from Ed Tomlinson <[EMAIL PROTECTED]> - > Hi, > > I do not know if this has been reported as a bug yet as the > bugs.debian.org page does not seem to work... > > I have just upgraded to woody (worked but was a little painfull). The > major reason for this was to get to XF4 and get DRI and dualhead > working with my matrox G400 MAX. Well I can get everything going > except that when drm is finally ready to enable DRI it fails since the > version reported my mga.o is 1.0.0 and the xserver wants 2.0.0 or > above. This is an upstream decision, I believe there are back port patches for the DRM modules to 2.2.x kernels, however I am not positive. Also I believe that the current 2.2.x pre kernels from Alan Cox have an up to date DRM module. The only thing we (Debian) can do to fix this is try and make sure that the kernel sources we package have the current DRM module patches. Zephaniah E. Hull. (The Debian developer who somehow got the 3Dfx issues, even under packages he does not maintain.) > > Before I go through the pain of learning how to rebuild the > package(s), will it work with dri 1.0.0 at all? If so are you > planning .debs for 2.2.18? In any case if it will work with dri 1.0.0 > just what packages need to be rebuilt? Do you have pointers to docs > on just how to rebuild them? > > TIA, > Ed Tomlinson <[EMAIL PROTECTED]> > > BTW xf86cfg fails here. first it cannot detect my usb mouse correctly. Once > I fixed the symlink in /dev it failed to autodetect the protocol needed. It > did write enought of an XF86Config to get X started after fixing the mouse up. > Then, when started under X, it complained that the cards DB was not found... > On irc I was advised to try dexter. Dexter will not generate anything but an > 3.3.6 version file for me... I did get it all working (manually) but thought > the above might help. -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Guns don't kill people. It's those damn bullets. Guns just make them go really really fast." -- Jake Johanson pgpDfwKpsblHP.pgp Description: PGP signature
Re: [tomlins@cam.org: DRI wth 2.2.18pre kernels]
Please don't send mail to Branden directly, questions such as this are much better suited for debian-x. > - Forwarded message from Ed Tomlinson <[EMAIL PROTECTED]> - > Hi, > > I do not know if this has been reported as a bug yet as the > bugs.debian.org page does not seem to work... > > I have just upgraded to woody (worked but was a little painfull). The > major reason for this was to get to XF4 and get DRI and dualhead > working with my matrox G400 MAX. Well I can get everything going > except that when drm is finally ready to enable DRI it fails since the > version reported my mga.o is 1.0.0 and the xserver wants 2.0.0 or > above. This is an upstream decision, I believe there are back port patches for the DRM modules to 2.2.x kernels, however I am not positive. Also I believe that the current 2.2.x pre kernels from Alan Cox have an up to date DRM module. The only thing we (Debian) can do to fix this is try and make sure that the kernel sources we package have the current DRM module patches. Zephaniah E. Hull. (The Debian developer who somehow got the 3Dfx issues, even under packages he does not maintain.) > > Before I go through the pain of learning how to rebuild the > package(s), will it work with dri 1.0.0 at all? If so are you > planning .debs for 2.2.18? In any case if it will work with dri 1.0.0 > just what packages need to be rebuilt? Do you have pointers to docs > on just how to rebuild them? > > TIA, > Ed Tomlinson <[EMAIL PROTECTED]> > > BTW xf86cfg fails here. first it cannot detect my usb mouse correctly. Once > I fixed the symlink in /dev it failed to autodetect the protocol needed. It > did write enought of an XF86Config to get X started after fixing the mouse up. > Then, when started under X, it complained that the cards DB was not found... > On irc I was advised to try dexter. Dexter will not generate anything but an > 3.3.6 version file for me... I did get it all working (manually) but thought > the above might help. -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Guns don't kill people. It's those damn bullets. Guns just make them go really really fast." -- Jake Johanson PGP signature
Re: [ketil@ii.uib.no: Re: [ketil@ii.uib.no: Bug#77511: relationships between packages for 3d support]]
On Wed, Nov 22, 2000 at 12:14:30AM +0100, Marcelo E. Magallon wrote: > >> "Zephaniah E. Hull" <[EMAIL PROTECTED]> writes: > > > I need to modify the glide2 and glide3 postinsts to be a little nicer > > about that, then tempt fate by asking -devel to let me make them > > standard. > > *blink* ... *blink* ... *BLINK* > > Make what standard? glide? Both glide2 and glide3, yes, this is not the best idea, but there are few good ones at the moment. > > > For a V2 you want libglide2, mesag3-glide2 > > Does this mean that it would be, uhm, bad if the mesa packages suddenly > drop support for glide? (if yes... damn!) Very bad. Zephaniah E. Hull. > > -- > M. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Here's your cable. We made it fifty feet long, just in case. In case what, in case tectonic movement makes the serial ports farther apart? -- Carl Jacobs on ASR. pgpSDc59Q21eR.pgp Description: PGP signature
Re: [ketil@ii.uib.no: Re: [ketil@ii.uib.no: Bug#77511: relationships between packages for 3d support]]
On Wed, Nov 22, 2000 at 12:14:30AM +0100, Marcelo E. Magallon wrote: > >> "Zephaniah E. Hull" <[EMAIL PROTECTED]> writes: > > > I need to modify the glide2 and glide3 postinsts to be a little nicer > > about that, then tempt fate by asking -devel to let me make them > > standard. > > *blink* ... *blink* ... *BLINK* > > Make what standard? glide? Both glide2 and glide3, yes, this is not the best idea, but there are few good ones at the moment. > > > For a V2 you want libglide2, mesag3-glide2 > > Does this mean that it would be, uhm, bad if the mesa packages suddenly > drop support for glide? (if yes... damn!) Very bad. Zephaniah E. Hull. > > -- > M. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Here's your cable. We made it fifty feet long, just in case. In case what, in case tectonic movement makes the serial ports farther apart? -- Carl Jacobs on ASR. PGP signature
Re: Bug#77130: dexter is not devfs ready
On Tue, Nov 21, 2000 at 06:33:17PM +0100, Goswin Brederlow wrote: > The check looks right but doesn't work: > > # grep '\.*devfs' /proc/mounts > > # grep '/dev\>.*devfs' /proc/mounts > > # grep '\ > # grep '/dev.*devfs' /proc/mounts > none /dev devfs rw 0 0 > > # grep ' /dev .*devfs' /proc/mounts > none /dev devfs rw 0 0 > > # grep '/dev.*devfs' /proc/mounts | hexdump > %07.7_ 6f6e 656e 2f20 6564 2076 6564 6676 2073 > %07.7_ 7772 3020 3020 000a > %07.7_ > > You might want to check for " " instead of word start and end to > circumvent the problem. Actually, / is not a word char, also, / tends to be special. grep '\/dev[\t ]*devfs' /proc/mounts Zephaniah E. Hull. > > MfG > Goswin > > PS: You might also check for existing devices when using devfs. I > don't have a /dev/tts/3, so theres no point giving me the > choise. Altough care must be taken to handle not yet loaded modules. I > might fill this as wishlist, since has nothing to do with this bug. Don't try to open, just test for existence. Zephaniah E. Hull. -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Microsoft is a cross between the Borg and the Ferengi. Unfortunately, they use Borg to do their marketing and Ferengi to do their programming." -- Simon Slavin in asr pgpR6A8Mlpgms.pgp Description: PGP signature
Re: Bug#77130: dexter is not devfs ready
On Tue, Nov 21, 2000 at 06:33:17PM +0100, Goswin Brederlow wrote: > The check looks right but doesn't work: > > # grep '\.*devfs' /proc/mounts > > # grep '/dev\>.*devfs' /proc/mounts > > # grep '\ > # grep '/dev.*devfs' /proc/mounts > none /dev devfs rw 0 0 > > # grep ' /dev .*devfs' /proc/mounts > none /dev devfs rw 0 0 > > # grep '/dev.*devfs' /proc/mounts | hexdump > %07.7_ 6f6e 656e 2f20 6564 2076 6564 6676 2073 > %07.7_ 7772 3020 3020 000a > %07.7_ > > You might want to check for " " instead of word start and end to > circumvent the problem. Actually, / is not a word char, also, / tends to be special. grep '\/dev[\t ]*devfs' /proc/mounts Zephaniah E. Hull. > > MfG > Goswin > > PS: You might also check for existing devices when using devfs. I > don't have a /dev/tts/3, so theres no point giving me the > choise. Altough care must be taken to handle not yet loaded modules. I > might fill this as wishlist, since has nothing to do with this bug. Don't try to open, just test for existence. Zephaniah E. Hull. -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Microsoft is a cross between the Borg and the Ferengi. Unfortunately, they use Borg to do their marketing and Ferengi to do their programming." -- Simon Slavin in asr PGP signature
Re: [ketil@ii.uib.no: Re: [ketil@ii.uib.no: Bug#77511: relationships between packages for 3d support]]
On Mon, Nov 20, 2000 at 10:32:24AM -0800, Seth Arnold wrote: > Sadly, the package system isn't mature enough (I don't think) to be able > to say, "if version x.x.x of package P is installed, then install > version y.y.y of package Q -- otherwise, install version z.z.z or > package R". Sigh, I suppose this means that someone (probably me, as I'm bringing it up) should write a program to look to see what video card you have, and spit out what packages should be installed, removed, and how they should be configured. Consider it added to the todo list, right after getting sst1 working again. (Don't ask, just, don't ask) > Well, I was hoping the Glide packages would be able to say "if you use > XFree86 v4, you don't need/shouldn't install this package". If that > is indeed the case. I need to modify the glide2 and glide3 postinsts to be a little nicer about that, then tempt fate by asking -devel to let me make them standard. (Right now, they yell loudly if you don't have a supported 3Dfx card installed, I need to change that so it will yell very quietly if you don't have a 3Dfx card, and yell loudly if you have a 3Dfx card it does not know about.) > > > and compounded by Debian's ability to have practically everything > > available installed at once. > > Yes. Shouldn't it be possible for Debian (or each of the > stable/unstable branches, at least) to standardize on a 3D > infrastructure? At least Woody ought, IMHO, to go towards adoption of > XFree/DRI, and warn against obsolescent packages that clutter up > things. But in many cases the 'obsolescent packages that clutter up things' are they ONLY way for the user to use 3D. > > > It is even more complex with 3dfx cards. (Zephaniah will attest to this > > in a heartbeat I think. :) > > I can't make mine work in Windows either, if that's a consolation. For a V2 you want libglide2, mesag3-glide2, and the dev3dfx kernel module, for a V4/V5 you want libglide3, xlibmesa3, X4, the kernel DRM module, and X4 using the DRI module. For a V3, you can use either, but not both. (Note, the V2 config works fine with X4, no worries there) > > You will also need the 3dfx kernel module > > There's source in Debian, too, for that matter. Which even works for both 2.2 and 2.4 kernels. Zephaniah E. Hull. > > Thanks, > > -kzm > -- > If I haven't seen further, it is by standing in the footprints of giants > > - End forwarded message - > > -- > ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all > really impressed down here, I can tell you.'' -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Be warned, I have a keyboard I can use to beat luser's heads in, and then continue to use... (=:] Mercury: Oh, an IBM. :) pgpzUaFCb87AE.pgp Description: PGP signature
Re: [ketil@ii.uib.no: Re: [ketil@ii.uib.no: Bug#77511: relationships between packages for 3d support]]
On Mon, Nov 20, 2000 at 10:32:24AM -0800, Seth Arnold wrote: > Sadly, the package system isn't mature enough (I don't think) to be able > to say, "if version x.x.x of package P is installed, then install > version y.y.y of package Q -- otherwise, install version z.z.z or > package R". Sigh, I suppose this means that someone (probably me, as I'm bringing it up) should write a program to look to see what video card you have, and spit out what packages should be installed, removed, and how they should be configured. Consider it added to the todo list, right after getting sst1 working again. (Don't ask, just, don't ask) > Well, I was hoping the Glide packages would be able to say "if you use > XFree86 v4, you don't need/shouldn't install this package". If that > is indeed the case. I need to modify the glide2 and glide3 postinsts to be a little nicer about that, then tempt fate by asking -devel to let me make them standard. (Right now, they yell loudly if you don't have a supported 3Dfx card installed, I need to change that so it will yell very quietly if you don't have a 3Dfx card, and yell loudly if you have a 3Dfx card it does not know about.) > > > and compounded by Debian's ability to have practically everything > > available installed at once. > > Yes. Shouldn't it be possible for Debian (or each of the > stable/unstable branches, at least) to standardize on a 3D > infrastructure? At least Woody ought, IMHO, to go towards adoption of > XFree/DRI, and warn against obsolescent packages that clutter up > things. But in many cases the 'obsolescent packages that clutter up things' are they ONLY way for the user to use 3D. > > > It is even more complex with 3dfx cards. (Zephaniah will attest to this > > in a heartbeat I think. :) > > I can't make mine work in Windows either, if that's a consolation. For a V2 you want libglide2, mesag3-glide2, and the dev3dfx kernel module, for a V4/V5 you want libglide3, xlibmesa3, X4, the kernel DRM module, and X4 using the DRI module. For a V3, you can use either, but not both. (Note, the V2 config works fine with X4, no worries there) > > You will also need the 3dfx kernel module > > There's source in Debian, too, for that matter. Which even works for both 2.2 and 2.4 kernels. Zephaniah E. Hull. > > Thanks, > > -kzm > -- > If I haven't seen further, it is by standing in the footprints of giants > > - End forwarded message - > > -- > ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all > really impressed down here, I can tell you.'' -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Be warned, I have a keyboard I can use to beat luser's heads in, and then continue to use... (=:] Mercury: Oh, an IBM. :) PGP signature
Re: Bug#77130: dexter is not devfs ready
On Mon, Nov 20, 2000 at 03:36:53AM +0100, Goswin Brederlow wrote: > Goswin > > PS: Using the old V3 config file for defaults and the console keymap > would be a good wishlist thing as well. Ow ow ow ow ow. No, you /really/ don't want those 'features'. Zephaniah E. Hull. -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Oh God yes, please, Espy...let me mount your hard-driving SPARCbeast until I undulate in X-compiling ecstasy pgpvso6F5hQ9f.pgp Description: PGP signature
Re: Bug#77130: dexter is not devfs ready
On Mon, Nov 20, 2000 at 03:36:53AM +0100, Goswin Brederlow wrote: > Goswin > > PS: Using the old V3 config file for defaults and the console keymap > would be a good wishlist thing as well. Ow ow ow ow ow. No, you /really/ don't want those 'features'. Zephaniah E. Hull. -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Oh God yes, please, Espy...let me mount your hard-driving SPARCbeast until I undulate in X-compiling ecstasy PGP signature
Re: 1600x1200 broken with vooodoo3 and NEC FP950
On Sun, Nov 19, 2000 at 02:20:23AM +, Matthew Garrett wrote: > On Fri, Nov 17, 2000 at 03:36:17PM +, Matthew Garrett wrote: > > > >From what I recall, dri didn't make any difference. I've a feeling > > >that it > > may have been dbe that reduced the corruption when removed, but I'll > > check that when I'm back with the machine this evening. > > Right. Removing DRI makes no difference to the graphics corruption. > Noaccel also doesn't seem to help. Odd, ok. This is Voodoo 3 specific, the Voodoo 4 and 5 seems to be immune, which makes it a little harder to pin down. (They share most of the 2D code) Zephaniah E. Hull. > > -- > Matthew Garrett | [EMAIL PROTECTED] -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "First they came for the Jews, and I didn't speak out - because I was not a jew. Then they came for the Communists, and I did not speak out - because I was not a Communist. Then they came for the trade unionists, and I did not speak out - because I was not a trade unionist. Then they came for me and there was no one left to speak for me!" - Pastor Niemoeller - victim of Hitler's Nazis pgp3Yv5MGxgSL.pgp Description: PGP signature
Re: 1600x1200 broken with vooodoo3 and NEC FP950
On Sun, Nov 19, 2000 at 02:20:23AM +, Matthew Garrett wrote: > On Fri, Nov 17, 2000 at 03:36:17PM +, Matthew Garrett wrote: > > > >From what I recall, dri didn't make any difference. I've a feeling > > >that it > > may have been dbe that reduced the corruption when removed, but I'll > > check that when I'm back with the machine this evening. > > Right. Removing DRI makes no difference to the graphics corruption. > Noaccel also doesn't seem to help. Odd, ok. This is Voodoo 3 specific, the Voodoo 4 and 5 seems to be immune, which makes it a little harder to pin down. (They share most of the 2D code) Zephaniah E. Hull. > > -- > Matthew Garrett | [EMAIL PROTECTED] -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "First they came for the Jews, and I didn't speak out - because I was not a jew. Then they came for the Communists, and I did not speak out - because I was not a Communist. Then they came for the trade unionists, and I did not speak out - because I was not a trade unionist. Then they came for me and there was no one left to speak for me!" - Pastor Niemoeller - victim of Hitler's Nazis PGP signature
Re: 1600x1200 broken with vooodoo3 and NEC FP950
On Thu, Nov 16, 2000 at 01:06:51PM +, Matthew Garrett wrote: > Yup. I switched to a V3 because my G100 wasn't capable of going past > 1800x1400, and managed to gain about an extra 60 pixels of horizontal > resolution before this bit me. At 16bpp it seems to appear at > 1872x1404 or higher. Gack. > Disabling all the loadable modules helps somewhat - then the garbage > is limited to the top of the screen rather than the entire display > being distorted. It happens with the upstream packages as well, so > it's not a Debian specific problem. I suspect that the only module which makes a difference on this is the DRI module, could you verify? > > Does XFree have any sort of bug tracking system? I've been assuming that > this is a known bug so haven't reported it, but being able to check that > would be handy. I'm not sure how XFree86 handles bug tracking, Branden should know though. Zephaniah E. Hull. > > -- > Matthew Garrett | [EMAIL PROTECTED] -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. *** Mercury has changed the topic on channel #debian-devel to: Mercury proposes some sense be beaten into CosmicRay and supporters. Merc's got my vote... god damn it, I don't want to be agreeing with Mercury what is it with this issue that makes the most unholy of alliances possible? pgpiDeL93nx7o.pgp Description: PGP signature
Re: 1600x1200 broken with vooodoo3 and NEC FP950
On Thu, Nov 16, 2000 at 01:06:51PM +, Matthew Garrett wrote: > Yup. I switched to a V3 because my G100 wasn't capable of going past > 1800x1400, and managed to gain about an extra 60 pixels of horizontal > resolution before this bit me. At 16bpp it seems to appear at > 1872x1404 or higher. Gack. > Disabling all the loadable modules helps somewhat - then the garbage > is limited to the top of the screen rather than the entire display > being distorted. It happens with the upstream packages as well, so > it's not a Debian specific problem. I suspect that the only module which makes a difference on this is the DRI module, could you verify? > > Does XFree have any sort of bug tracking system? I've been assuming that > this is a known bug so haven't reported it, but being able to check that > would be handy. I'm not sure how XFree86 handles bug tracking, Branden should know though. Zephaniah E. Hull. > > -- > Matthew Garrett | [EMAIL PROTECTED] -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. *** Mercury has changed the topic on channel #debian-devel to: Mercury proposes some sense be beaten into CosmicRay and supporters. Merc's got my vote... god damn it, I don't want to be agreeing with Mercury what is it with this issue that makes the most unholy of alliances possible? PGP signature
Re: 1600x1200 broken with vooodoo3 and NEC FP950
On Wed, Nov 15, 2000 at 11:09:03AM -0800, Jason Mealins wrote: > Just upgraded from 3.3.6 to 4.0.1-3 and 1600x1200 no longer works, > every res below it does. There is no log errors, just when 1600x1200 > launches, it scruches the entire screen to the top of the monitor. This seems to be a known issue, I can't fix it personally because I can't reproduce it because, well, my monitor sucks, can't go to a high enough res to get the problem. :/ > Can't figure out what has been changed. between the two. Any help > would be great. also tdfx doesn't allow me to run at 32bit anymore. Try 24bpp, that works. Zephaniah E. Hull. (Debian glide maintainer, and generally the guy who gets to deal with odd 3Dfx bugs.) > > Jason Mealins > [EMAIL PROTECTED] -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Guns don't kill people. It's those damn bullets. Guns just make them go really really fast." -- Jake Johanson pgpVkNnQkizCp.pgp Description: PGP signature
Re: 1600x1200 broken with vooodoo3 and NEC FP950
On Wed, Nov 15, 2000 at 11:09:03AM -0800, Jason Mealins wrote: > Just upgraded from 3.3.6 to 4.0.1-3 and 1600x1200 no longer works, > every res below it does. There is no log errors, just when 1600x1200 > launches, it scruches the entire screen to the top of the monitor. This seems to be a known issue, I can't fix it personally because I can't reproduce it because, well, my monitor sucks, can't go to a high enough res to get the problem. :/ > Can't figure out what has been changed. between the two. Any help > would be great. also tdfx doesn't allow me to run at 32bit anymore. Try 24bpp, that works. Zephaniah E. Hull. (Debian glide maintainer, and generally the guy who gets to deal with odd 3Dfx bugs.) > > Jason Mealins > [EMAIL PROTECTED] -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Guns don't kill people. It's those damn bullets. Guns just make them go really really fast." -- Jake Johanson PGP signature
Re: voodoo3 libgl error in woody xf4
On Sat, Nov 11, 2000 at 05:02:13AM +0500, James Leigh wrote: > really? (=0 > > I would really like to use branden's xf4 fully, but it never used the > accl. opengl libraries for me. What is it that you did? How can I get > my system to drop the rpms from linux.3dfx.com ? I should tell you know > that I have change back to 2.2.17, because I could not get bttv to work > with 2.4.0. I do have tdfx as a module for 2.2.17. > So you do not have glide-v3-dri, and tdfx-dri install right? How were > you able to do that? What GL libraries did you use? You want libglide3 and xlibmesa3. Zephaniah E. Hull. (The glide maintainer.) -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Pshaw! *I* am a paid-up member of the Mystic Order of Arachnid Vigilance." "Please. Why don't you go fight evil somewhere else? I'm trying to sleep here." -- Rodger Donaldson and Eric The Read in alt.sysadmin.recovery pgpU3t0KiSeHM.pgp Description: PGP signature
Re: voodoo3 libgl error in woody xf4
On Sat, Nov 11, 2000 at 05:02:13AM +0500, James Leigh wrote: > really? (=0 > > I would really like to use branden's xf4 fully, but it never used the > accl. opengl libraries for me. What is it that you did? How can I get > my system to drop the rpms from linux.3dfx.com ? I should tell you know > that I have change back to 2.2.17, because I could not get bttv to work > with 2.4.0. I do have tdfx as a module for 2.2.17. > So you do not have glide-v3-dri, and tdfx-dri install right? How were > you able to do that? What GL libraries did you use? You want libglide3 and xlibmesa3. Zephaniah E. Hull. (The glide maintainer.) -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. "Pshaw! *I* am a paid-up member of the Mystic Order of Arachnid Vigilance." "Please. Why don't you go fight evil somewhere else? I'm trying to sleep here." -- Rodger Donaldson and Eric The Read in alt.sysadmin.recovery PGP signature
Re: [BUG]: X crash when on console with DRI
Known issue with TDFX and the DRI module, I'm working on it. For now you can comment out the 'Load "dri"' line in /etc/X11/XF86Config-4. This is definately becoming a FAQ. -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Espy: oh yes, Espy, let me ride your sparcbeast pgpfGq9GnvHAG.pgp Description: PGP signature
Re: [BUG]: X crash when on console with DRI
Known issue with TDFX and the DRI module, I'm working on it. For now you can comment out the 'Load "dri"' line in /etc/X11/XF86Config-4. This is definately becoming a FAQ. -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Espy: oh yes, Espy, let me ride your sparcbeast PGP signature
Re: voodoo3 libgl error in woody xf4
On Tue, Nov 07, 2000 at 07:38:21PM -0500, jamie wrote: > Greetings, > > i have recently installed the woody xf4 debs my system with a voodoo3 > card and things are working fine, except for opengl acceleration. > > my kernel: 2.4.0-test10 w/ tdfx compiled into the kernel (and agppart > enabled) > vid card: voodoo3 2000 agp > mobo: asus a7v > > However, GL programs (xscreensaver hacks, etc) do not run accelerated. > I get the following results: > > $ export LIBGL_DEBUG="on" > $ gears > libGL error: dlopen failed: undefined > symbol:_trisetup_Default_win_nocull_valid WTF!? > > and glxinfo reports: > display: :0.0 screen:0 > direct rendering: No Hrrrm. > > any suggestions would be _greatly_ appreciated. i can send full > XFree86.log (though i don't think there are no EE or relavent WW lines) > or /XF86Config-4 if it'd help... Yes, please do. Zephaniah E. Hull. (The Debian glide guy, who somehow got dragged into X work, ugh.) > > thanks in advance. > > -jamie walker > [EMAIL PROTECTED] -- PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. I still do not understand why manglement believes that cutting off the oxygen flow to the brain will INCREASE productivity. The reason they made that decision is probably because they couldn't think clearly due to wearing neckties. -- Paul Tomko on ASR. pgp2P46cLoEYW.pgp Description: PGP signature
