Direct2Dell

Sankarshan:  A real hardware test kit is not as easy as it might seem. It is at best a quick scan of that needs to be verified by hand. I wrote a hardware test kid for a distribution two years ago that covered various hardware. The problem is the thing was not going to be able to test every peace of hardware completely. You can check if graphics acceleration is enabled and work to find out it didn't really work or modem connectivity worked except it did so at half-speed. A modem that works does not mean the advertised fax capabilities work. The list of problems with a hardware test kit go on. You need to know a thing or two and do allot more checking than simply running a script or hardware test program to check compatibility.

Thanks for replying to my suggestion. Unfortunately, I don't think I can provide any insight into convertng SUSE's hardware format. It might also be nice to try to coordinate this effort with http://hardware4linux.info .

I appreciate DELL's helping Linux streamline its hardware detection infrastructure -- active cooperation from hardware vendors is just what is needed.

This is an excellent development.

 I do support what Matt said about pluggable information - much like printer PPDs that can be easily manually installed.

There are a number of other areas of hardware information where Dell could do *much* better. For example, sound card pin configuration, see http://lists.us.dell.com/pipermail/linux-desktops/2007-September/000622.html

 In that case, correct pin configuration was not achieved until 1.5 years after the release of the laptops, which is horrible for the users. And even then, I'm pretty sure many models were missed, and some details overlooked. Dell could do much better here as well.
 

Pluggable upstream information.

 I do not believe that a full upstream is a complete solution.  Most OEMs should provide information for their systems as an adjunct to their systems.

 This will mean that an OEM must have something akin to a HW support package that contains the vital stats of their system.  So long as a distribution supports importing the file format, it makes it a lot easier for users to match any hardware configuration with the a set of Dell hwinfo package.

This should allow a higher level of customization and direct user->OEM interaction that easily demonstrates a level of commitment to users. Rather than push upstream and wait the 6-12 months before the distributions update their packages, at HW launch time, the OEM can post the package and provide updates directly.

 This also allows more direct relationships between OEMs and OSVs to provide the sort of information that ajax refers to.

Some time back I had mused about a hardware test kit. 

The major problem I have with MonitorsDB in its current form is that the format just doesn't specify enough information. Sync ranges are not enough. In fact for monitors like the 3007WFP they're actively wrong, because they imply that the monitor itself can do a range of modes, and it really can't.

We need to come up with a better long-term solution.  And I think that solution is just EDID with serial numbers scrubbed out.  If Dell has reference EDID blocks for their monitors internally, I'd happily start bootstrapping this.

This is a big mess... Each kernel driver has PCI IDs in random places, as do X.org drivers, kde-guidance, Yast, Sax2, Hal. Speaking of HAL, wouldn't HAL-info be a more suitable place for hwdata?

http://gitweb.freedesktop.org/?p=hal-info.git;a=tree 

Any chance you could leave some helpful hints on how to contribute?

Now I have two Dell monitors, both listed already, but anyway... Would be nice to know if I run into something not listed in the future. =) 

 I guess you should start by finding out what frequencies the monitor supports from the manual, and compare to what edid data says and possibly look at the .INF file shipped for use with Windows. Still, would be nice if someone who's not just speculating wrote a few lines about it. =)