Re: PCI autodetection
On Thu, Oct 05, 2000 at 07:22:41PM -0400, Will Lowe wrote: > I'll look at it. I'm using a table of device->driver mappings I stole > from RH 6.2, so unless it has the X info, I don't. Some time ago (actually it must be 0.5 to 1 year ago now) I also started implementing a pci hardware detection. Because of time reasons it got stuck... During that time I examined the source of RedHat's tools and I am pretty sure it had mapping device->xserver in it... (Actually I had a kind of detection of some kind of kernel modules and xserver working, but it was only an ugly hack) Roland -- Roland Bauerschmidt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
Please don't CC me on replies. > A generic svga at 1024x768@60Hz should be a good default in most situations > if nothing else is found. Hrm, I'd rather not contribute to workplace violence in the United States by defauling to a refresh rate that is guaranteed to result in psychosis. > Consider also that we could detect automatically the monitor model and video > frequencies with read-edid, which can be found at: > > http://web.onetel.net.uk/~elephant/john/programs/linux/read-edid/ Thanks for pointing this out; I will check into it. -- G. Branden Robinson |The key to being a Southern Baptist: Debian GNU/Linux|It ain't a sin if you don't get caught. [EMAIL PROTECTED] |-- Anthony Davidson http://www.debian.org/~branden/ | PGP signature
Re: PCI autodetection
> Well, it looks like everybody's doing the same thing at the same time. > > At Progeny, Joseph Carter has been developing a libdetect based program > called "discover" which spits out the correct X server (for 3.x) or X > server and driver (for 4.x) given the PCI info. > > I'm writing a program called "dexter" (for Debian X server configurator) > which uses this information if it is present. > > I don't know when Joseph plans to submit his discover program to Debian, > but dexter (and modified xserver-* postinst scripts to take advantage of > it) will be showing up in phase2v14. > > Dexter is presently feature-complete for Progeny's purposes. Also, I'm > deliberately doing things in such a way that there is no need for a fork > between Progeny's X packages and Debian's. If Dexter doesn't find > /var/state/discover/video, it prompts the user for the server (or > server+driver) to use, which isn't really worse than the present way of > doing things. > > -- > G. Branden Robinson | It doesn't matter what you are doing, > Debian GNU/Linux| emacs is always overkill. > [EMAIL PROTECTED] | -- Stephen J. Carpenter > http://www.debian.org/~branden/ | A generic svga at 1024x768@60Hz should be a good default in most situations if nothing else is found. Consider also that we could detect automatically the monitor model and video frequencies with read-edid, which can be found at: http://web.onetel.net.uk/~elephant/john/programs/linux/read-edid/ -- Massimo Dal Zotto +--+ | Massimo Dal Zotto email: [EMAIL PROTECTED] | | Via Marconi, 141phone: ++39-0461534251 | | 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ | | Italy pgp: see my www home page | +--+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
> While you're at it -- perhaps you could try to come up with some > patches against xviddetect so it knows about more cards? It really > only knows pathetically few right now. See the bugs against that > package too. woah if you want to add more things to xviddetect, file bugs or email me. there are only a small number of cards (3?) reported to be not yet detected in the bts. most of them were actually added to a rejected upload to potato. i can reupload it for 2.2r1 if needed. i haven't heard that xvidetect knows about "pathetically few" cards... Adam, where did you hear that from? randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
Excellent. Will, let us know what else we can do to help. -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
On Thu, Oct 05, 2000 at 07:22:41PM -0400, Will Lowe wrote: > > That would be cool. You wanna patch dbootstrap -- we could even make > > that conditional on the pci stuff being there at all.. > > I'm in the midst of building a patch to dboostrap now. I'll throw in a > check to see if /proc/bus/pci exists, and if not we'll skip the "do you > want to autodetect PCI devices" question altogether. > > > Please don't commit into mainstream boot-floppies yet -- it needs more > > help. > > No prob. I'll send the patch to this list when it's done. > > > While you're at it -- perhaps you could try to come up with some > > patches against xviddetect so it knows about more cards? It really > > I'll look at it. I'm using a table of device->driver mappings I stole > from RH 6.2, so unless it has the X info, I don't. > > > If you're not a Debian maintainer, I'm happy to do NMU's against Well, it looks like everybody's doing the same thing at the same time. At Progeny, Joseph Carter has been developing a libdetect based program called "discover" which spits out the correct X server (for 3.x) or X server and driver (for 4.x) given the PCI info. I'm writing a program called "dexter" (for Debian X server configurator) which uses this information if it is present. I don't know when Joseph plans to submit his discover program to Debian, but dexter (and modified xserver-* postinst scripts to take advantage of it) will be showing up in phase2v14. Dexter is presently feature-complete for Progeny's purposes. Also, I'm deliberately doing things in such a way that there is no need for a fork between Progeny's X packages and Debian's. If Dexter doesn't find /var/state/discover/video, it prompts the user for the server (or server+driver) to use, which isn't really worse than the present way of doing things. -- G. Branden Robinson | It doesn't matter what you are doing, Debian GNU/Linux| emacs is always overkill. [EMAIL PROTECTED] | -- Stephen J. Carpenter http://www.debian.org/~branden/ | PGP signature
Re: PCI autodetection
> That would be cool. You wanna patch dbootstrap -- we could even make > that conditional on the pci stuff being there at all.. I'm in the midst of building a patch to dboostrap now. I'll throw in a check to see if /proc/bus/pci exists, and if not we'll skip the "do you want to autodetect PCI devices" question altogether. > Please don't commit into mainstream boot-floppies yet -- it needs more > help. No prob. I'll send the patch to this list when it's done. > While you're at it -- perhaps you could try to come up with some > patches against xviddetect so it knows about more cards? It really I'll look at it. I'm using a table of device->driver mappings I stole from RH 6.2, so unless it has the X info, I don't. > If you're not a Debian maintainer, I'm happy to do NMU's against I am; [EMAIL PROTECTED] Will -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
Will Lowe <[EMAIL PROTECTED]> writes: > Right. I'm adding a step just before the user is presented with the list > of modules that asks if the user would like to try autoprobing for PCI > devices. That would be cool. You wanna patch dbootstrap -- we could even make that conditional on the pci stuff being there at all.. Please don't commit into mainstream boot-floppies yet -- it needs more help. While you're at it -- perhaps you could try to come up with some patches against xviddetect so it knows about more cards? It really only knows pathetically few right now. See the bugs against that package too. If you're not a Debian maintainer, I'm happy to do NMU's against xviddetect for potato if they will increase it's usefulness. -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
> busybox and mini-grep are on the root filesystem, not the base set. Right. I realized this later last night. So I rewrote the whole thing in ash, and it's now down to 2k (after gzip -9). It will, of course, get larger as the table grows when new hardware is added. > Sure, of course. The 'configure drivers' step. Right. I'm adding a step just before the user is presented with the list of modules that asks if the user would like to try autoprobing for PCI devices. Will -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
> Please don't forget that debian supports machines without pci bus. What would > your changes to boot floppies do if this is the case ? Nothing. The program that does autopci detection just says "Can't find PCI bus" and you go one to configure the drivers the old way. > Also, it would be nice to add support for other kind of buses. zorro > for amiga like hardware (you can use zorroutils i guess) for example. I don't have an amiga to try this on. > I think other supported non pci bus include the sbus based sparc > boxes. Don't know about those though. Sparcs use sbus and/or PCI, depending on the Sparc you've got. As I mentioned before, _just_ autodetecting PCI cards will cover a _large_ number of cases, so that's what I'm shooting for. If someone else with an Amiga wants to do the same thing for zorro, I'll help if I can. Will -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
Will Lowe <[EMAIL PROTECTED]> writes: > (I just remembered:) > > The reason I did it in C rather than in ash was that I wanted the program > to be usable _before_ base.tar.gz is untarred (and hence before grep and > the rest of busybox is available) busybox and mini-grep are on the root filesystem, not the base set. > -- I'd like dbootstrap to be able to > probe the PCI devices and find the network card, configure the network, > and _then_ fetch the base filesystem. :) Sure, of course. The 'configure drivers' step. -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
On Tue, Oct 03, 2000 at 04:20:23PM -0400, Will Lowe wrote: > I've put together (from pciutils and Redhat's anaconda) a small program > that asks the kernel about devices on the PCI bus and loads (or lists )the > needed driver modules. This hopefully enables NIC autodetection for > anyone who's using a PCI nic. > > You can grab the current version of the code from (please read the README) > http://openrock.net/~lowe/pcidetect/ > > I'm in the midst of building a patch against boot-floppies that will run > the autoprober first by default and then allow users to manually configure > additional modules; hopefully I'll be done with that in the next day or > two. Please don't forget that debian supports machines without pci bus. What would your changes to boot floppies do if this is the case ? Also, it would be nice to add support for other kind of buses. zorro for amiga like hardware (you can use zorroutils i guess) for example. I think other supported non pci bus include the sbus based sparc boxes. Don't know about those though. Friendly, Sven LUTHER -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
> I suppose I could write a shell script to do the same thing, looking at > /proc/bus/pci/devices instead of asking the kernel directly, and keep the > table as text ... (I just remembered:) The reason I did it in C rather than in ash was that I wanted the program to be usable _before_ base.tar.gz is untarred (and hence before grep and the rest of busybox is available) -- I'd like dbootstrap to be able to probe the PCI devices and find the network card, configure the network, and _then_ fetch the base filesystem. :) Will -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
> this is really just like what xviddetect/anXious does; you just have a > db of kernel modules instead of Xserver names Yes. It's something of a pain because it means you've (I've) got to keep the table up to date as new drivers are written or old ones expanded, but I don't see how else it can really be done. Will -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
In reference to a message from Will Lowe, dated Oct 03: > I've put together (from pciutils and Redhat's anaconda) a small program > that asks the kernel about devices on the PCI bus and loads (or lists )the > needed driver modules. This hopefully enables NIC autodetection for > anyone who's using a PCI nic. this is really just like what xviddetect/anXious does; you just have a db of kernel modules instead of Xserver names randolph -- Debian Developer <[EMAIL PROTECTED]> http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
> > If you're not already gzip'ing the vendor/device id table this could be > > an option for reducing it. > That doesn't matter since the root filesystem is gzipped anyhow. Actually, in order to reduce the amount of parsing needing to be done by the program, I've got a perl script that builds a .h file containing the table (as an array of structs) which is then #included into the binary. I suppose I could write a shell script to do the same thing, looking at /proc/bus/pci/devices instead of asking the kernel directly, and keep the table as text ... Will -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
Will Lowe <[EMAIL PROTECTED]> writes: > > For boot-floppies for Potato? I am not sure we'd be allowed to add > > this sort of change to potato -- anaconda isn't included in Potato. > > This is _hacked_ from anaconda, but isn't anaconda itself. It's one > smallish (22k if you build the "tiny" version) binary. It can't get a > whole lot smaller because of the table needed to make vendor/device ids to > driver names, but if anyone has any suggestions for reducing the > footprint, I'd be happy to hear them. > > I'm hacking into into the potato boot-floppies because I need it for > another Debian-derived project, whether or not Debian wants to try to put > it into one of the 2.2rX releases. Hmm. It's possible. Obviously I can't rely on stuff which is not in boot-floppies (or debian-boot) CVS area or else packaged and in stable. > I know that the current thinking is that boot-floppies will disappear for > woody, but it seems like this code could be useful in whatever will > replace it also. Sure. I'm not sure i, for woody, stuff like this ought to be packaged separately or provided as a udpkg package. -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
Ray Knight <[EMAIL PROTECTED]> writes: > If you're not already gzip'ing the vendor/device id table this could be > an option for reducing it. That doesn't matter since the root filesystem is gzipped anyhow. -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
Will Lowe wrote: > > > For boot-floppies for Potato? I am not sure we'd be allowed to add > > this sort of change to potato -- anaconda isn't included in Potato. > > This is _hacked_ from anaconda, but isn't anaconda itself. It's one > smallish (22k if you build the "tiny" version) binary. It can't get a > whole lot smaller because of the table needed to make vendor/device ids to > driver names, but if anyone has any suggestions for reducing the > footprint, I'd be happy to hear them. > If you're not already gzip'ing the vendor/device id table this could be an option for reducing it. -- Ray Knight [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
> For boot-floppies for Potato? I am not sure we'd be allowed to add > this sort of change to potato -- anaconda isn't included in Potato. This is _hacked_ from anaconda, but isn't anaconda itself. It's one smallish (22k if you build the "tiny" version) binary. It can't get a whole lot smaller because of the table needed to make vendor/device ids to driver names, but if anyone has any suggestions for reducing the footprint, I'd be happy to hear them. I'm hacking into into the potato boot-floppies because I need it for another Debian-derived project, whether or not Debian wants to try to put it into one of the 2.2rX releases. I know that the current thinking is that boot-floppies will disappear for woody, but it seems like this code could be useful in whatever will replace it also. Will -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
Will Lowe <[EMAIL PROTECTED]> writes: > I've put together (from pciutils and Redhat's anaconda) a small program > that asks the kernel about devices on the PCI bus and loads (or lists )the > needed driver modules. This hopefully enables NIC autodetection for > anyone who's using a PCI nic. > > You can grab the current version of the code from (please read the README) > http://openrock.net/~lowe/pcidetect/ > > I'm in the midst of building a patch against boot-floppies that will run > the autoprober first by default and then allow users to manually configure > additional modules; hopefully I'll be done with that in the next day or > two. For boot-floppies for Potato? I am not sure we'd be allowed to add this sort of change to potato -- anaconda isn't included in Potato. Hmmm. -- .Adam Di [EMAIL PROTECTED]http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
PCI autodetection
I've put together (from pciutils and Redhat's anaconda) a small program that asks the kernel about devices on the PCI bus and loads (or lists )the needed driver modules. This hopefully enables NIC autodetection for anyone who's using a PCI nic. You can grab the current version of the code from (please read the README) http://openrock.net/~lowe/pcidetect/ I'm in the midst of building a patch against boot-floppies that will run the autoprober first by default and then allow users to manually configure additional modules; hopefully I'll be done with that in the next day or two. Will -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
PCI autodetection
Last night I put together some code from pciutils and Redhat's anaconda and came up with a little program that asks the kernel about installed PCI hardware and modprobes the needed drivers, using a little table. I don't know if it's useful or not for the next incarnation of boot-floppies, but you can grab the code from http://openrock.net/~lowe/pcidetect/pcidetect-1.0.tar.gz Will -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
