Re: Automatically installing hardware specific packages
[Petter Reinholdtsen] > Are there better ways to do this? Anyone willing to work on it? One alternative would be to move the information out of the discover-data package, and into the Packages file instead, similar to how Iceweasel[1] and Moonlight[2] might find their plugins and codec packages, and store USB and PCI ids there. [1] https://wiki.ubuntu.com/FlashExperienceIntrepid [2] http://wiki.debian.org/Teams/DebianMonoGroup/Moonlight The idea I got was to add headers like this to the package supporting specific hardware, and use this information to look up the USB and PCI ids present in the machine: Xb-Hardware-Bus-PCI: 1af4:1002 Xb-Hardware-Bus-USB: 1d6b:0001 This way the build system for the X video card packages could extract the list of PCI devices supported by the driver and include it in the control file of the package, and the RAID controller packages could list the supported hardware ids too. It would get rid of the central hardware->package directory, and probably scale better than the discover-pkginstall approach. A problem with this approach is that some packages support a lot of PCI ids, and another is that some packages support ranges of ids or classes of devices. Not sure how that is best represented in a Packages file. > Fedora 13 provides PackageKit to install hardware specific packages > after installation. Perhaps we should extend the discover system to > listen to DBus events and install hardware packages also after > installation? Or port PackageKit to Debian and use it instead? Anyone know how this work? > Anyway, a draft system is in d-i at the moment, and I welcome help > with updating the hardware mappings to get more packages installed > automatically by d-i. :) I got a bunch of updates, and these are now in the discover-data package in unstable and testing, but I am sure there are more hardware specific packages out there, and very much welcome more mappings.:) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2fl7hlywz4v@login2.uio.no
Re: Automatically installing hardware specific packages
On Wed, Jun 16, 2010 at 21:33:52 +0200, Petter Reinholdtsen wrote: > The idea I got was to add headers like this to the package supporting > specific hardware, and use this information to look up the USB and PCI > ids present in the machine: > > Xb-Hardware-Bus-PCI: 1af4:1002 > Xb-Hardware-Bus-USB: 1d6b:0001 > > This way the build system for the X video card packages could extract > the list of PCI devices supported by the driver and include it in the > control file of the package > We did something like that in lenny (not in the Packages file, but same basic idea), to get X to choose the right driver. It turns out it's a pain to maintain, and doesn't really work all that well. We should just install xserver-xorg-video-all. Maybe for other cases it's different, I don't know. Cheers, Julien signature.asc Description: Digital signature
Re: Automatically installing hardware specific packages
Petter Reinholdtsen writes: > [Petter Reinholdtsen] >> Are there better ways to do this? Anyone willing to work on it? > > One alternative would be to move the information out of the > discover-data package, and into the Packages file instead, similar to > how Iceweasel[1] and Moonlight[2] might find their plugins and codec > packages, and store USB and PCI ids there. > > [1] https://wiki.ubuntu.com/FlashExperienceIntrepid > [2] http://wiki.debian.org/Teams/DebianMonoGroup/Moonlight > > The idea I got was to add headers like this to the package supporting > specific hardware, and use this information to look up the USB and PCI > ids present in the machine: > > Xb-Hardware-Bus-PCI: 1af4:1002 > Xb-Hardware-Bus-USB: 1d6b:0001 And subdevice ids and class ids and more buses and ... > This way the build system for the X video card packages could extract > the list of PCI devices supported by the driver and include it in the > control file of the package, and the RAID controller packages could > list the supported hardware ids too. It would get rid of the central > hardware->package directory, and probably scale better than the > discover-pkginstall approach. > > A problem with this approach is that some packages support a lot of > PCI ids, and another is that some packages support ranges of ids or > classes of devices. Not sure how that is best represented in a > Packages file. Why not reuse the module alias syntax for the hardware application database as well? It allows for a number of different bus configurations, not only pci and usb, with class matches where appropriate. And it is a well known syntax. And it buys you easy direct matching against /sys/devices/.../modalias Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ocfavi9k@nemi.mork.no
Re: Automatically installing hardware specific packages
[Julien Cristau] > We did something like that in lenny (not in the Packages file, but > same basic idea), to get X to choose the right driver. It turns out > it's a pain to maintain, and doesn't really work all that well. Why was it a pain to maintain? I can imagine it is a pain if there is no automatic way to extract the supported ids from the source code (like it is/was with X). But if it is possible to extract it automatically like is done with kernel modules, I believe it should not be too hard. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100616202354.gi15...@login2.uio.no
Re: Automatically installing hardware specific packages
On Wed, Jun 16, 2010 at 22:23:54 +0200, Petter Reinholdtsen wrote: > [Julien Cristau] > > We did something like that in lenny (not in the Packages file, but > > same basic idea), to get X to choose the right driver. It turns out > > it's a pain to maintain, and doesn't really work all that well. > > Why was it a pain to maintain? > > I can imagine it is a pain if there is no automatic way to extract the > supported ids from the source code (like it is/was with X). But if it > is possible to extract it automatically like is done with kernel > modules, I believe it should not be too hard. > The pci ids were extracted from the source code with awk or sed or whatever. They were also wrong, because things like matching for a range of chips [0] or looking for the actual chip id in mmio space [1] weren't taken into account. [0] http://cgit.freedesktop.org/xorg/driver/xf86-video-nv/tree/src/nv_driver.c#n798 [1] http://cgit.freedesktop.org/xorg/driver/xf86-video-nv/tree/src/nv_driver.c#n717 Cheers, Julien signature.asc Description: Digital signature
Re: Automatically installing hardware specific packages
Le mercredi 16 juin 2010 à 21:33 +0200, Petter Reinholdtsen a écrit : > > Fedora 13 provides PackageKit to install hardware specific packages > > after installation. Perhaps we should extend the discover system to > > listen to DBus events and install hardware packages also after > > installation? Or port PackageKit to Debian and use it instead? > > Anyone know how this work? PackageKit is not suitable for Debian, but Ubuntu reimplemented the same D-Bus interface on top of aptdaemon (session-installer). It has recently entered unstable. This interface is able to install packages given their name - if it’s only for that, you can also use aptdaemon directly, the only advantage is that it’s the same as Fedora’s. In all cases this implies writing a session daemon that listens to events when hardware is plugged, and asks the user for conformation before installing hardware-specific packages. I don’t know whether the stuff from Fedora can be re-used. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Automatically installing hardware specific packages
On Wed, 2010-06-16 at 21:33 +0200, Petter Reinholdtsen wrote: > [Petter Reinholdtsen] > > Are there better ways to do this? Anyone willing to work on it? > > One alternative would be to move the information out of the > discover-data package, and into the Packages file instead, similar to > how Iceweasel[1] and Moonlight[2] might find their plugins and codec > packages, and store USB and PCI ids there. > > [1] https://wiki.ubuntu.com/FlashExperienceIntrepid > [2] http://wiki.debian.org/Teams/DebianMonoGroup/Moonlight > > The idea I got was to add headers like this to the package supporting > specific hardware, and use this information to look up the USB and PCI > ids present in the machine: > > Xb-Hardware-Bus-PCI: 1af4:1002 > Xb-Hardware-Bus-USB: 1d6b:0001 > > This way the build system for the X video card packages could extract > the list of PCI devices supported by the driver and include it in the > control file of the package, and the RAID controller packages could > list the supported hardware ids too. It would get rid of the central > hardware->package directory, and probably scale better than the > discover-pkginstall approach. [...] This probably makes some sense for userland drivers that bind to specific PCI and USB devices, and for any OOT kernel drivers. For applications and userland drivers that depend on specific kernel drivers it would make more sense for the package to specify the kernel driver(s) and for the package manager to look at which drivers have been loaded and bound to devices. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Automatically installing hardware specific packages
On Wed, Jun 16, 2010 at 11:09:32PM +0200, Josselin Mouette wrote: > Le mercredi 16 juin 2010 à 21:33 +0200, Petter Reinholdtsen a écrit : > > > Fedora 13 provides PackageKit to install hardware specific packages > > > after installation. Perhaps we should extend the discover system to > > > listen to DBus events and install hardware packages also after > > > installation? Or port PackageKit to Debian and use it instead? > > > > Anyone know how this work? Basically PackageKit is just a common interface and a daemon to handle transactions. The work is done by backends. The PackageKit daemon just receives the request for a driver and routes it to the backend. But you also need some client tools: The always running gpk-update-icon and the DBus activated gpk-service tools from gnome-packagekit. Both run in the user session and listen to the session D-Bus. The tools provide the end user dialogs and guide the user through the installation process: AFAIK there are currently 3 ways to install drivers/firmware: * gpk-update-icon which is part of gnome-packagekit monitors /dev/.udev/firmware-missing * gpk-update-icon listens to the DeviceAdded signal of hal * gpk-service provides a InstallPrinterDriver method. I think that it called by the cups management application The above clients call the WhatProvides method of the system PackageKit daemon to query the corresponding packages. Which is implemented differently by each backend. I haven't looked at the details of the yum backend which is used by Fedora. The apt and aptcc backend don't provide any firmware/driver query capabilities. Furthermore there is a small tool in packgekit which rebinds devices to tigger the loading of a recently installed firmware. > PackageKit is not suitable for Debian, but Ubuntu reimplemented the same > D-Bus interface on top of aptdaemon (session-installer). It has recently > entered unstable. Actually aptdaemon and sessioninstaller are not implemented by "Ubuntu", but I get a lot of support and patches from Michael Vogt and Matthew Paul Thomas. Canonical's software-center is "just" the main user. I started to work on the projects since I was a little bit frustrated about the design limits of PackageKit. The packagekit daemon wants to keep things simple and provide a complete backend for a basic package manager - including search operations. In contrast aptdaemon only handles the core methods which require root privileges - but making use of advanced features (e.g. debconf support, config file handling and since recently plugins and future cache calculation). The system DBus interface of aptdaemon is not compatible with the one of PackageKit. The search and query operations should be handled by the client applications since a modern package management GUI needs a lot of distro specific information, see software-center compared to gpk-application or kpackagekit. > This interface is able to install packages given their name - if it’s > only for that, you can also use aptdaemon directly, the only advantage > is that it’s the same as Fedora’s. Sessioninstaller implements the session DBus interface of PackageKit which is provided by gnome-packagekit and kpackagekit, but uses synaptic or aptdaemon for the installation. The interfaces should stay compatible in the future, since third party software is supposed to call the session interface to install software, plugins, fonts, printer drivers or gstreamer resources. The system interface should only be called by fully blown package managers. Sessioninstaller currently supports installing by file name (requires apt-file), by gstreamer resources and by mime type handler (requires app-install-data). Printer drivers and fonts are not supported, since there isn't yet any corresponding infrastructure in Debian or Ubuntu. If you want to extend the interface we could discuss this on the PackageKit list. Richard is generally open to improvements. > In all cases this implies writing a session daemon that listens to > events when hardware is plugged, and asks the user for conformation > before installing hardware-specific packages. I don’t know whether the > stuff from Fedora can be re-used. I remember vaguely the hermes project of Guadalinex - an Ubuntu derivate of the Spanish administration. It provided nearly the same functionality. But it was some years back when I looked at the code. Finally there is also jockey of Ubuntu. But I am not familiar with it. Cheers, Sebastian signature.asc Description: Digital signature
Re: Automatically installing hardware specific packages
[Sebastian Heinlein] > Basically PackageKit is just a common interface and a daemon to handle > transactions. The work is done by backends. The PackageKit daemon just > receives the request for a driver and routes it to the backend. > > But you also need some client tools: The always running gpk-update-icon > and the DBus activated gpk-service tools from gnome-packagekit. Both run > in the user session and listen to the session D-Bus. The tools provide the > end user dialogs and guide the user through the installation process: Would you be interested in testing in Debian Edu/Squeeze a setup using the packagekit interface to dynamically install hardware specific packages when they are discovered? If we get it working there in time for Squeeze, we can try to get it integrated into the normal Debian desktop too. :) If so, please join us on #debian-edu (irc.debian.org) to discuss how. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2fl4ogsvmnq@login1.uio.no
