 So welcome to my talk about hardware detection in Debian My name is Pette Reinholson. I'm the maintainer of discover. I've been working on xdeb configurator and a few other related packages And the reason I'm giving this talk is that I believe we can do a lot better It's not to say that we are doing it badly at the moment But there is some advantages we could use could gain if we made it even more advanced the current hardware detection system I'm going to do a quick summary of the current state of hardware detection and then provide some ideas for a future system and Hopefully attract enough interest to be able to get some volunteers to implement this new hardware detection system for Lenny At the moment We are doing quite well how many has installed Woody in the audience. Do you remember the list of? modules to load a Few hundreds you can pick the ones you wanted and leave the rest out very nice and You had full control over your installation system anyone miss it and This is like One step of the hardware detection getting the correct curl modules loaded at install time Another step of on the way is the loading the correct modules at runtime when you boot or later on And this is mostly taken care of by the kernel developers They've made sure that all the kernel modules provide information about what kind of hardware they support and debus no and You dev at the moment It's notified by the kernel when a module should be loaded and it takes care of the kernel module Loading using the information provided by the kernel developers the same thing is Well, this will take care of all PCI devices because PCI devices provide information about their identity so you can actually Detect which device it is and then you know what kind of module to load USB is also working like that In previous times it was not like this you had the isa cards which would Not tell the system what they were what kind of Device they were so we would end up probing the the system in various ways to see if it reacted correctly and if it did you had the Appropriate device if it didn't it could do like it could lock up the system It could crash the machine it could destroy your data it could do anything so that kind of probing was not a great success But it was very implementous implement a very easy to implement from a hardware point of view and that's why it was done in the 80s and 90s Luckily PCI came along and solved that part of the problem But the PCI IDs is only solving part of the problem for hardware detection for instance CPUs Normally would need some special kernel modules for CPU frequency scaling and this there is no way at the moment to detect when Kernel module like that is needed also some laptops like my think pad would work better if I load a module to use the acceleration sensors within the laptop to Provide information to a demon that will park the hard disk when when the laptop is falling basically As far as I know there is no way to detect when to load that module Using information provided by the Linux kernel and other tools So we need to come up with a way to detect when Those modules should be loaded Of course kernel modules is only part of the problem X drivers is next problem and At the moment that is solved by providing a mapping from PCI IDs to X drivers manually in the discover data packet There is also the kudzu packet from red hat the hw info from Susa and a bunch of other packages within Debian That provides similar information, but as you can imagine Maintaining that kind of database is a Lot of work and it tends to be always too late Because we are waiting for Users to complain that their new video card doesn't work Then we can find out their IDs and then we can add it to the database and then we can make a new release And this normally takes two years before the video card starts working I've been talking to the X extra dog developers and They agreed to provide some kind of List of supported devices information in the drivers themselves Like the kernel modules do at the moment So the X drivers would know and present that information to the installation system. So the Installation system can pick the right driver or Even more advanced if they are successful with this the X server itself can Do the correct auto configuration as David Newsen of Spoke about earlier in his X talk so this is Progressing quite nicely, but this is only taking care of two parts of the system kernel modules and Video drivers there is quite a lot of hardware hardware specific stuff that could be loaded at install time or runtime if we Provided the infrastructure for it. For example, my laptop would is using the internet Intel video card from like from IBM and There is a packet in the archive that would allow me to control that video card a bit better We could install these kind of packages automatically when we just we discovered the appropriate hardware This is not done at the moment, but it would be fairly easy to do and I provided a Draft implementation of such mechanism in the discovered to version to packet the discover dash packet install will probe the system and look up the hardware devices in the database and Proposed packages to install if it detects The correct video card the correct rate controller that kind of thing And I hope we can take this one step further and make sure this is done during installation and during runtime Wouldn't it be nice if you plug in your scanner on your already installed Debian system and a dialogue box dialogue box pops up and say I noticed you installed a scanner Do you want me to install saying as well? And then you just place click yes and all the scanner software is installed and it works out of the box We can get there if you want to Another thing we will experience our user will experience is that You have some hardware installed on your network and there is nothing actually stopping us from detecting new piece of hardware on the network say you have a scanner printer wireless Box installed on your network. It should be possible for the computer to detect that. Oh, there is a printer Connected to your network. Do you want to configure it pops up a dialogue box and use press yes, and that takes care of the rest That's where I want Debian to be no other system provides this Windows if the drivers is available on the Windows install media can provide something like that, but Of course with their Mechanism for licensing. They don't have the option of downloading the source or the software and installing it automatically So the problem of course is how do we make this happen? Someone needs to do the work and As you can imagine, I don't plan to do it myself I've done some of it, but I'm unlikely to manage to Copied all the projects I have before Lenny So I'm hoping to attract the volunteers to Implements part implement parts of this for the local devices which you plug in after install time. I suspect it's easier to Make use of the debas and how the hardware abstraction layer and have some listener on the user's desktop detecting when the new hardware is added to the machine and then we can Look up the hardware in the hardware database And if a match is found with packages that is not installed at the moment We can pop up some dialogue proposing to install that packet of course it will need some Mechanism to detect if it's a KDE or GNOME environment or if it's a console environment and Pick the right packets and I have no firm Suggest on how to actually detect which packet to install One idea is to look at the list of dependence new dependencies and only in or suggest to install The packet with the least amount of new dependencies This of course will Probably detect if the KDE or GNOME version of a program should be proposed, but it will not Handle properly the case where you have a really bad program with few dependencies and a good program with many dependencies And you really want to propose the one with a lot of dependencies But I'm suspect that this should be like a few weeks programming to get up and running it depends of course on the hardware database and I have no idea how to implement or to maintain that automatically because We need to know what kind of hardware maps to what kind of packages and that's not recorder recorded in a Structured way in over there been packages at the moment and I'm not quite sure if it's going to be possible to do that either So for now, I suspect we have to maintain that database manually To reduce the amount of work at least for the discover to a packet We should probably restructure the way discover do it at the moment It's currently a two-layer system where you have the Hardware ID and then you have the data about the hardware ID Which would be kernel module or packet name or video driver and that kind of thing To a two-step operation where you have the PCI ID or the USB ID and then you have the kernel module And then you have packets because normally packages packages support Kernel APIs, which would be kernel modules and they don't support hardware Well, very rarely support hardware directly you still would have to have the direct mapping But the indirect mapping would reduce the amount of work required to maintain such database As you would only list a packet once Supporting a specific driver and then you list all the Hardware supported by this driver in a separate set of a separate part of the database This is not implemented at the moment, but should be doable also adding support for more Types of hardware would solve part of the problem with CPU frequency modules if we can detect modules based on the CPU name type Provided for example by Proc CPU info or DMI Decode that could be useful to detect and load the correct kernel module in that case DMI decode can also be used for detecting and loading the correct modules for IPMI, which is used by Servers to provide information about CPU fan speed and Temperature inside the the box At the moment DMI seem to be the only source of information that can be used to detect if IPMI is supported or not and for Network detection Avanti seem to be a good choice for detecting when Units appear on your network at least printers seem to announce their presence using the discover Protocol Don't remember the exact name of that one, but it's the automatic network configuration protocol So if we can hook into Avanti we can make sure we send some kind of debus event to the Listener on the desktop and that can pop up with a dialogue explaining that There is a new printer available on the network. Do you want to configure it? So that's that's my general vision for Lenny. I think It would improve the user experience quite a lot and reduce the time that maintainers system administrators and and people administrating a lot of computers would have to spend to Keep their systems correctly configured and hopefully make Debbie on the best Distribution when it comes to hardware detection and handling of Hardware at the moment as I said, we are not doing very badly, but we are We have quite a large Area where we can improve so that's the Draft of my proposal and the questions Yeah, it's works the question is you Thought about how to detect the package which is should be installed if there is some certain hardware So I wonder if we could use perhaps the depth tax techniques to for instance user tech supports hardware whatever and so Do you think it would be helpful helpful? maybe the first simple cases it could be used because Simple cases have only one supported device or at least a specific device is supported, but for some drivers The support the devices is not a specific set of devices or like a range of PCI IDs or Device PCI IDs with this kind of structure No, I'm very hard to represent in a tag system. I mean more generally so for instance sauna Supports hardware scanner or something like this and then if if the scanner is detected Everything which has this tech it will be installed I think I don't think that would have would work because it has to be very specific to the Exact hardware you have Or else it will provide options that are not really working for your hardware Okay More questions What is your method that to detect the new hardware plug-in or are connected to the network? network such as You can deal it with a system service or and so on. I want to know I want to know the method you want to detect the new new hardware I Don't understand the question. Can you repeat it? or that's My question is that if you want to To detect the new hardware that plug-in the system or connect on the connected in the network that you need a method how to to to To do to do it such as the kuzu. Do you know kuzu right hand? It's a system service It's a service demon Right, and I want to know the Your idea about it how to to do it right My idea for that is the debus Every time you plug anything into the machine Event is generated on the debus and everything listening on the debus can pick up that event and act on it if they want to so if you if one implements a Desktop client that listens to for that kind of events and Process them and look for packages to install or stuff like that. It will just work So it would depend on debus. You could also do as we do at the moment Scan the buses and report the detected hardware and act on those then you don't need a demon But that that's would only work during boot or install time It will not work when you are using the desktop or using the machine So my proposal is to use the debus for that and of course the kernel modules are already loaded like that because debus is getting Message and you dev is picking up. I think and the kernel modules is loaded There's a question over there one thing that happens sometimes is the hardware exists on the System but then only is supported in later kernels. So when you install a new kernel you finally get a You know the the hardware existed all along, but you can finally use it You have any plans for well to you install a kernel now? I have to do the hardware detection for the existing hardware again. I Think that would happen automatically if you use the debus When the system boots it will announce the presence of all the hardware in the machine and if the system detects if that there is a packet to be installed or some Configuration to be done. It will just pop up and do it It's kind of hard to distinguish between the case of oh the hardware existed already And he said he didn't want to install the the packages. So you have to keep track of oh this hardware existed I don't want to detect it again, but this hardware existed, but I couldn't use it before Well, not really because it would only happen during boot time that the events about the presence that the installed hardware is present So they wouldn't keep popping up because the events would not be sent after the install install after the boot Other questions I think that Maybe we do the sink too complex because If we found a printer we should put the configuration part on our printer system it can be caps or LPR NGE or so if we found a scanner We put the part the configuration part of In the scanner system, so we we will do a simpler system Because I think that anyway the The printer subsystem should detect hardware so it should not do twice the same work Well, sure you shouldn't do it twice and yes, you should definitely activate the correct subsystem to do the configuration So if it is a scanner you should activate the scanner subsystem Which is called saying at the moment and if you are detecting a printer you should activate the cups Framework to do the configuration But the point is that at the moment there is only the cups framework that do detect printers The same framework do not another but the system can Send Send message to the new to the over printer subsystem This detection system Give some ink to the overseas team Well, sure, I suspect when you detect a printer you would start or point the browser to the cups website and Feed some useful information to it so it knows what it's a spec. It is expected to do So definitely yes, don't you don't want to have two different kind of configuration sets for printers and scanners You want to use the existing subsystems? Another feature I didn't mention but I think it should be possible to do automatically at install time or runtime is To handle the current Source packages in Debian for kernel modules So if you detect some hardware supported by that source module it will Install the source automatically and build the module automatically and load it automatically to get these extra kernel modules working out of the box any more questions and then volunteers to implement this and no one know how to use the debus and Make a graphical user interfaces, you know, there seem to be no more questions. So thank you