The Fedora Hardware Project

[Maxwell Kanat-Alexander]

That's what I'm calling it for right now. Feel free to recommend any
name you desire.

The updated specification/summary for the project is up at:

<http://people.ucsc.edu/~maxka/fhp/>

I expect that to be a very temporary location -- the space may
disappear any day now.

Let me know if anybody else has any more ideas, now that we've got them
in a more manageable and organized form.

-M

[Bill Nottingham]

Post by Maxwell Kanat-Alexander
<http://people.ucsc.edu/~maxka/fhp/>
I expect that to be a very temporary location -- the space may
disappear any day now.
Let me know if anybody else has any more ideas, now that we've got them
in a more manageable and organized form.

Random comments from looking over it for the first time...

Storing brand names is a pain, as there will be 4000 branding variants
of a particular device. (Video cards are a classic example, there are
5000 ways to spell out GeForce2). When you have large amounts of
user data like this, you'll need a good way to go through and
verify all the submissions for typos, variations in spelling,
variations in wording, etc. Otherwise the list can become
unmanageable.

Having a system card URL can lead to privacy concerns.

One of the issues you'll have to deal with is only presenting
to the user the 'interesting' hardware. In general, the user
isn't going to be able to diagnose efficiently enough to the
hardware tool whether or not their PCI bridge works. On the
other end, when you deal with something like a hard drive, there
are 4000 models, most all of which work exactly the same.

One comment made:
"HWBrowser seems to make sense of hardware data somehow -- is there
a way to get data out of it? Who's the maintainer of hwbrowser?"

hwbrowser just calls libkudzu; that data is easily available.

Bill

[Maxwell Kanat-Alexander]

Post by Bill Nottingham
Storing brand names is a pain, as there will be 4000 branding variants
of a particular device.

I was hoping for people to use the pre-entered ones for their chipset
ID, mostly, and making it slightly difficult to enter a new one.

I can see your point, there, though.

The problem is: Users will want to search for brand names.

Are there other resolutions to this issue?

Perhaps there's a way to get a canonical sort of brand name out of DMI.

Post by Bill Nottingham
Having a system card URL can lead to privacy concerns.

I see the point, here. We'll have to give people the option to make
their system private or public, something like MadOnion.com (or whatever
it's called now) does with their 3DMark results and the related
hardware.

Post by Bill Nottingham
One of the issues you'll have to deal with is only presenting
to the user the 'interesting' hardware.

From lspci, at least, we have a "hardware type", like "USB Controller."
We'd probably have to keep up, somewhat, on the hardware types, and make
sure that we filter what we ask the user about based on that.

Post by Bill Nottingham
In general, the user
isn't going to be able to diagnose efficiently enough to the
hardware tool whether or not their PCI bridge works. On the
other end, when you deal with something like a hard drive, there
are 4000 models, most all of which work exactly the same.

I would hope that for things like disk drives, we could just run some
basic diagnostics and leave the user alone.

Post by Bill Nottingham
hwbrowser just calls libkudzu; that data is easily available.

Thanks.

-M

[Bill Nottingham]

Post by Maxwell Kanat-Alexander

Post by Bill Nottingham
Storing brand names is a pain, as there will be 4000 branding variants
of a particular device.

I was hoping for people to use the pre-entered ones for their chipset
ID, mostly, and making it slightly difficult to enter a new one.
I can see your point, there, though.
The problem is: Users will want to search for brand names.
Are there other resolutions to this issue?

Well, if you have a place for an alternate brand name, you can
enter it there, so people could search that way.

(The other place this will hit is on motherboard sound chipsets;
the variation in names for something that turns out to either be
one of a) i810_audio b) via82cxxx_audio is rather staggering. :) )

Post by Maxwell Kanat-Alexander
Perhaps there's a way to get a canonical sort of brand name out of DMI.

Not for anything attached in a slot, no.

Post by Maxwell Kanat-Alexander

Post by Bill Nottingham
One of the issues you'll have to deal with is only presenting
to the user the 'interesting' hardware.

From lspci, at least, we have a "hardware type", like "USB Controller."
We'd probably have to keep up, somewhat, on the hardware types, and make
sure that we filter what we ask the user about based on that.

That's pretty easy to do. Only a subset of the PCI ids are really
interesting.

Bill

[Nicolas Mailhot]

Post by Bill Nottingham

Post by Maxwell Kanat-Alexander
<http://people.ucsc.edu/~maxka/fhp/>
I expect that to be a very temporary location -- the space may
disappear any day now.
Let me know if anybody else has any more ideas, now that we've got them
in a more manageable and organized form.

Random comments from looking over it for the first time...
Storing brand names is a pain, as there will be 4000 branding variants
of a particular device. (Video cards are a classic example, there are
5000 ways to spell out GeForce2).

However the pci db people have been doing it for years
It's not rocket science : you just print out the entries that have
already associated to the id and/or entries for similar hardware and
people will choose by themselves something that fits.

(you still need someone to manually review stuff however)

Cheers,

[Maxwell Kanat-Alexander]

Post by Nicolas Mailhot

Post by Bill Nottingham
Storing brand names is a pain, as there will be 4000 branding variants
of a particular device. (Video cards are a classic example, there are
5000 ways to spell out GeForce2).

However the pci db people have been doing it for years
It's not rocket science : you just print out the entries that have
already associated to the id and/or entries for similar hardware and
people will choose by themselves something that fits.

Hrm... seems like that where the brand name comes from should be a
configurable data source. For PCI, we could use the pci db, perhaps. For
other buses, we could use already-existing projects, or we could make
our own. If somebody started a project, we could give them our data and
reconfigure our database to pull from theirs.

-M

[David Zeuthen]

Post by Bill Nottingham
Storing brand names is a pain, as there will be 4000 branding variants
of a particular device. (Video cards are a classic example, there are
5000 ways to spell out GeForce2). When you have large amounts of
user data like this, you'll need a good way to go through and
verify all the submissions for typos, variations in spelling,
variations in wording, etc. Otherwise the list can become
unmanageable.

Note that PCI has the concept of both (vendor_id, product_id) and
(subsystem_vendor_id, subsystem_product_id). Now, for instance, all
videocards with GeForce 2 MX chipsets will (as I understand it) report
the same (vendor_id, product_id); the integrator, e.g. the name that is
on the shrink-wrapped box, will set only the subsystem* parameters.

It doesn't appear that USB supports this concept unfortunatly.

The pci.ids and usb.ids database will help you map the *_id numbers
to names.

Cheers,
David

[Nicolas Mailhot]

Post by David Zeuthen
It doesn't appear that USB supports this concept unfortunatly.
The pci.ids and usb.ids database will help you map the *_id numbers
to names.

usb returns cleartext vendor/product - so it's better out of the box
than pci.

[Bill Nottingham]

Post by David Zeuthen
Note that PCI has the concept of both (vendor_id, product_id) and
(subsystem_vendor_id, subsystem_product_id). Now, for instance, all
videocards with GeForce 2 MX chipsets will (as I understand it) report
the same (vendor_id, product_id); the integrator, e.g. the name that is
on the shrink-wrapped box, will set only the subsystem* parameters.

Exactly. Upstream in pci.ids the subsystem/subdevice is only
spottily populated though; probablyy because for operational
purposes you just don't care.

Bill