On Wed, Apr 21, 2010 at 7:08 AM, Peter Robinson pbrobinson@gmail.com wrote:
I've spent a little time looking at the hardware side of things and done a basic patch for some of the hardware stuff based on the current rawhide comps file. I've broken it down into network/server/misc for the time being and pushed the print stuff over to its group. More can be done as it was a quick look through. The old hardware-support currently includes all the other groups so there's no real change for current builds overall.
This looks like a good start. I think the way this kind of thing should work in general is that the system detects if you have the hardware, and dynamically installs support for it. We'd need some database mapping things like USB ids to packages. Networking is an exception; we should include as many drivers/tools for networking-related functionality as possible so that the system can be bootstrapped.
Basically: if you have a GPS chip, gypsy gets installed and runs. If you don't, it doesn't.
On Wed, Apr 21, 2010 at 2:40 PM, Colin Walters walters@verbum.org wrote:
On Wed, Apr 21, 2010 at 7:08 AM, Peter Robinson pbrobinson@gmail.com wrote:
I've spent a little time looking at the hardware side of things and done a basic patch for some of the hardware stuff based on the current rawhide comps file. I've broken it down into network/server/misc for the time being and pushed the print stuff over to its group. More can be done as it was a quick look through. The old hardware-support currently includes all the other groups so there's no real change for current builds overall.
This looks like a good start. I think the way this kind of thing should work in general is that the system detects if you have the hardware, and dynamically installs support for it. We'd need some database mapping things like USB ids to packages. Networking is an exception; we should include as many drivers/tools for networking-related functionality as possible so that the system can be bootstrapped.
Well basically the way I've done the first swipe above won't impact anything that just includes @hardware-support as it just includes all groups. Those that want to drop stuff can register specific groups. I was thinking of making hardware-support-network hardware-support-wireless but then realises there was a couple of DSL firmwares in the list. In most cases for a server this would make no difference as servers don't generally have wireless and if there is any wired server ethernet in there I would probably move it to server but I think they're all contained in linux-firmware anyway.
Basically: if you have a GPS chip, gypsy gets installed and runs. If you don't, it doesn't.
Agreed. But in the interim until we get pci/usb id matching I figured this would be a good start.
Is it OK to push it to rawhide, are we too late in the process for F-13 given the default doesn't change any of the standard builds?
Peter
Peter Robinson (pbrobinson@gmail.com) said:
Agreed. But in the interim until we get pci/usb id matching I figured this would be a good start.
Is it OK to push it to rawhide, are we too late in the process for F-13 given the default doesn't change any of the standard builds?
Not for F-13, no matter what.
Bill
On Wed, 2010-04-21 at 09:40 -0400, Colin Walters wrote:
This looks like a good start. I think the way this kind of thing should work in general is that the system detects if you have the hardware, and dynamically installs support for it. We'd need some database mapping things like USB ids to packages.
When doing this, please do the obvious thing and store the match information in modalias format:
atropine:~% modinfo appledisplay | grep alias alias: usb:v05ACp921Dd*dc*dsc*dp*ic03isc*ip00* alias: usb:v05ACp9219d*dc*dsc*dp*ic03isc*ip00* alias: usb:v05ACp9218d*dc*dsc*dp*ic03isc*ip00*
system-config-display uses .xinf files in basically this format (tuple of (alias, driver) one per line) to match video devices to drivers. It works well, which is probably the only thing in s-c-d you can say that about. Sample python code to do the match (please steal):
http://git.fedorahosted.org/git/?p=system-config-display.git;a=blob;f=src/al...
Ideally we work out a way to jam this into rpm Provides.
- ajax
On Wed, 2010-04-21 at 09:40 -0400, Colin Walters wrote:
This looks like a good start. I think the way this kind of thing should work in general is that the system detects if you have the hardware, and dynamically installs support for it. We'd need some database mapping things like USB ids to packages. Networking is an exception; we should include as many drivers/tools for networking-related functionality as possible so that the system can be bootstrapped.
Basically: if you have a GPS chip, gypsy gets installed and runs. If you don't, it doesn't.
I've been banging a gong about something like that for years; right now it's much too hard to know what you're supposed to do to make $RANDOM_GADGET that you just plugged in actually work, but we can hardly install the software for every USB device under the sun by default. There's a clear need for something like this. Really it's just a kind of widget that sits between udev and PackageKit, I think.
On Wed, Apr 21, 2010 at 4:17 PM, Adam Williamson awilliam@redhat.com wrote:
On Wed, 2010-04-21 at 09:40 -0400, Colin Walters wrote:
This looks like a good start. I think the way this kind of thing should work in general is that the system detects if you have the hardware, and dynamically installs support for it. We'd need some database mapping things like USB ids to packages. Networking is an exception; we should include as many drivers/tools for networking-related functionality as possible so that the system can be bootstrapped.
Basically: if you have a GPS chip, gypsy gets installed and runs. If you don't, it doesn't.
I've been banging a gong about something like that for years; right now it's much too hard to know what you're supposed to do to make $RANDOM_GADGET that you just plugged in actually work, but we can hardly install the software for every USB device under the sun by default. There's a clear need for something like this. Really it's just a kind of widget that sits between udev and PackageKit, I think.
Dumb question.... Can't the usb printer autoinstall just be extended to support other hardware? Based on usb/pci ids?
Peter
On 21 April 2010 16:17, Adam Williamson awilliam@redhat.com wrote:
I've been banging a gong about something like that for years; right now it's much too hard to know what you're supposed to do to make $RANDOM_GADGET that you just plugged in actually work, but we can hardly install the software for every USB device under the sun by default. There's a clear need for something like this. Really it's just a kind of widget that sits between udev and PackageKit, I think.
It already exists, and is the GpkHardware GObject that lives in gnome-packagekit. In Fedora we disable it by default, but Suse use it to great affect. Fedora just uses GpkFirmware which intercepts missing firmware requests from the kernel and offers to install the firmware and then soft-replug the device.
The hard bit (and why it's disabled in Fedora) is working out what software needs to be installed for a given bit of hardware. It's really the kind of thing that needs to be added to udev as just a simple rule, and then enabled in gnome-packagekit.
Richard.
On 21 April 2010 16:40, Richard Hughes hughsient@gmail.com wrote:
software needs to be installed for a given bit of hardware. It's really the kind of thing that needs to be added to udev as just a simple rule, and then enabled in gnome-packagekit.
Of course, the packages also need rpm provides. The hard bit is working out from a sysfs path "this is a GPS device" and then gpk can install any software that provides "hardwaresupport(gps)"
Richard.
On Wed, 2010-04-21 at 16:45 +0100, Richard Hughes wrote:
On 21 April 2010 16:40, Richard Hughes hughsient@gmail.com wrote:
software needs to be installed for a given bit of hardware. It's really the kind of thing that needs to be added to udev as just a simple rule, and then enabled in gnome-packagekit.
Of course, the packages also need rpm provides. The hard bit is working out from a sysfs path "this is a GPS device" and then gpk can install any software that provides "hardwaresupport(gps)"
Except that the software for enabling the hardware is most likely different from the software to use the hardware.
As long as only front-end applications have those provides and drag in all the dependencies they need, it would probably be fine. Or you'd need to be able to install them as package sets.
Hi,
(Dropping devel, cross-posting is evil etc. etc.)
On Wed, 2010-04-21 at 09:40 -0400, Colin Walters wrote:
On Wed, Apr 21, 2010 at 7:08 AM, Peter Robinson pbrobinson@gmail.com wrote:
I've spent a little time looking at the hardware side of things and done a basic patch for some of the hardware stuff based on the current rawhide comps file. I've broken it down into network/server/misc for the time being and pushed the print stuff over to its group. More can be done as it was a quick look through. The old hardware-support currently includes all the other groups so there's no real change for current builds overall.
This looks like a good start. I think the way this kind of thing should work in general is that the system detects if you have the hardware, and dynamically installs support for it. We'd need some database mapping things like USB ids to packages. Networking is an exception; we should include as many drivers/tools for networking-related functionality as possible so that the system can be bootstrapped.
Basically: if you have a GPS chip, gypsy gets installed and runs. If you don't, it doesn't.
Don't take this mail the wrong way, but I strongly object to something like that. It is a departure from how things currently work e.g. we install all drivers/software/etc for any gizmo you may or may not plug in. While the current approach certainly represent a cost (bandwidth, diskspace, etc.) I find it highly preferable to some unreliable auto-detection system that is very very hard to get right and comes with its own set of problems (See non-OEM installs of Windows for details).
My view is that there's are a couple of corner cases where doing something like the proposed might work (printer drivers comes to mind) but for core hardware support it is just bound to fail. And it doesn't really buy you anything. Granted, it's an interesting problem to solve and I guess that's why people keep advocating such a system. But for a free OS developed in a centralized way (for better or worse) it's pretty much just fail city.
(FWIW, here's an idea: I think we should work towards everyone getting everyone the same goddamn OS image (which is thoroughly tested, QA'ed etc etc) instead of making the current time-space combinatorics thing we're doing right now even harder and more complex.)
David
On Wed, 2010-04-21 at 13:58 -0400, David Zeuthen wrote:
I've spent a little time looking at the hardware side of things and done a basic patch for some of the hardware stuff based on the current rawhide comps file. I've broken it down into network/server/misc for the time being and pushed the print stuff over to its group. More can be done as it was a quick look through. The old hardware-support currently includes all the other groups so there's no real change for current builds overall.
This looks like a good start. I think the way this kind of thing should work in general is that the system detects if you have the hardware, and dynamically installs support for it. We'd need some database mapping things like USB ids to packages. Networking is an exception; we should include as many drivers/tools for networking-related functionality as possible so that the system can be bootstrapped.
Basically: if you have a GPS chip, gypsy gets installed and runs. If you don't, it doesn't.
Don't take this mail the wrong way, but I strongly object to something like that. It is a departure from how things currently work e.g. we install all drivers/software/etc for any gizmo you may or may not plug in.
We don't do anything like this at present. There are all sorts of packages which are useful only to some specific piece of hardware which we do not install by default. Off the top of my head I can think of synce (for manipulating Windows Mobile phones), barry (for Blackberries) and Concordance (for handling Logitech remote controls). The list is probably endless. Right now we more or less install most of what you need for the things we sort of consider integral bits of the system, but certainly not for peripherals.
Adam Williamson (awilliam@redhat.com) said:
We don't do anything like this at present. There are all sorts of packages which are useful only to some specific piece of hardware which we do not install by default. Off the top of my head I can think of synce (for manipulating Windows Mobile phones), barry (for Blackberries)
The right answer for these is a single syncing framework that DTRT whether it's a WinMo, Andriod, BlackBerry, iPhone, or whatever; not random phone-specific packages.
and Concordance (for handling Logitech remote controls).
Given that this is a remote programming tool (as opposed to a tool for *using* the remote), it's likely to be special.
Bill
On Wed, 2010-04-21 at 14:32 -0400, Bill Nottingham wrote:
Adam Williamson (awilliam@redhat.com) said:
We don't do anything like this at present. There are all sorts of packages which are useful only to some specific piece of hardware which we do not install by default. Off the top of my head I can think of synce (for manipulating Windows Mobile phones), barry (for Blackberries)
The right answer for these is a single syncing framework that DTRT whether it's a WinMo, Andriod, BlackBerry, iPhone, or whatever; not random phone-specific packages.
Exactly - I think it would be wise to focus our quite limited resources to the cases where there is a mature driver framework available. This includes kernel drivers, X.org drivers, libgphoto2, sane and a couple of other things. And for this, we should just install everything by default.
Sure, ideally we'd support as much hardware out of the box as possible but if it involves installing multiple apps that overlap in functionality.. then the solution is NOT to install each app depending on what the user plugs in or have already plugged in... clearly the solution is to invest in fixing this miserable situation by creating a driver (kernel- or user-mode) framework and porting the driver code to this framework. And then installing the best app for this by default including all the driver software.
For the record, this is quickly becoming less and less of a problem. Most modern hardware (except things like video drivers) is driven by either a class protocol (such as usb-storage, PTP etc) or handled via online services (e.g. your phone syncs with a server on the Internet).
There's a bunch of other reasons why "install XYZ when detecting ABC" is a really bad idea (useless prompts asking "ABC was detected but you need XYZ to drive it" or "to install XYZ enter the ROOT password"). Again, I urge you to examine a non-OEM version of Windows.
David
On Wed, 2010-04-21 at 15:20 -0400, David Zeuthen wrote:
There's a bunch of other reasons why "install XYZ when detecting ABC" is a really bad idea (useless prompts asking "ABC was detected but you need XYZ to drive it" or "to install XYZ enter the ROOT password"). Again, I urge you to examine a non-OEM version of Windows.
That was always how I would assume it would work. Of course it shouldn't install software without asking the user first. A pop-up saying 'you should probably install package XYZ to use your ABC' is clearly the only sensible way to do it.
On Wed, 2010-04-21 at 12:31 -0700, Adam Williamson wrote:
On Wed, 2010-04-21 at 15:20 -0400, David Zeuthen wrote:
There's a bunch of other reasons why "install XYZ when detecting ABC" is a really bad idea (useless prompts asking "ABC was detected but you need XYZ to drive it" or "to install XYZ enter the ROOT password"). Again, I urge you to examine a non-OEM version of Windows.
That was always how I would assume it would work. Of course it shouldn't install software without asking the user first. A pop-up saying 'you should probably install package XYZ to use your ABC' is clearly the only sensible way to do it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
I think David is saying that all these popups is a problem, not a solution.
On Wed, 2010-04-21 at 14:32 -0400, Bill Nottingham wrote:
Adam Williamson (awilliam@redhat.com) said:
We don't do anything like this at present. There are all sorts of packages which are useful only to some specific piece of hardware which we do not install by default. Off the top of my head I can think of synce (for manipulating Windows Mobile phones), barry (for Blackberries)
The right answer for these is a single syncing framework that DTRT whether it's a WinMo, Andriod, BlackBerry, iPhone, or whatever; not random phone-specific packages.
There is one, it's called opensync. synce, barry (and various other bits for other phones) ultimately use opensync for the actual synchronization stuff. But the layer between the generic framework (opensync) and the phone OS is different in each case. Even if they were all part of the same 'project' they'd be packaged as separate plugins and I doubt anyone would want to install every plugin on every system.
and Concordance (for handling Logitech remote controls).
Given that this is a remote programming tool (as opposed to a tool for *using* the remote), it's likely to be special.
Guessing isn't always a good idea. =) You can't use a Harmony remote without programming it; out of the box they do absolutely nothing. You have to 'program' it for the actual components you want it to control. Concordance does this.
These were simply examples. There's zillions of them. We certainly don't install every package we provide for certain hardware peripherals out of the box, I don't think that can be debated.
Adam Williamson (awilliam@redhat.com) said:
Given that this is a remote programming tool (as opposed to a tool for *using* the remote), it's likely to be special.
Guessing isn't always a good idea. =) You can't use a Harmony remote without programming it; out of the box they do absolutely nothing. You have to 'program' it for the actual components you want it to control. Concordance does this.
I know what it is. What I mean is that concordance isn't a tool for letting you use the remote as a peripheral with the OS. It's the equivalent of a JTAG programmer.
BIll
On Wed, 2010-04-21 at 15:40 -0400, Bill Nottingham wrote:
Adam Williamson (awilliam@redhat.com) said:
Given that this is a remote programming tool (as opposed to a tool for *using* the remote), it's likely to be special.
Guessing isn't always a good idea. =) You can't use a Harmony remote without programming it; out of the box they do absolutely nothing. You have to 'program' it for the actual components you want it to control. Concordance does this.
I know what it is. What I mean is that concordance isn't a tool for letting you use the remote as a peripheral with the OS. It's the equivalent of a JTAG programmer.
That's hair-splitting. Ultimately the problem is the same. If you buy a Harmony and you have Windows or OS X, you're fine. It comes with a software disc and instructions on what to do; it's obvious how to set it up. If you use Linux, it's not at all obvious; there is software but you have to find that out and install it yourself. If you just plug it into your system, nothing at all happens, and it's easy to conclude there's no way to use it. It would clearly be much better if, when you plugged in the remote to your Linux system, something notified you that software is available to let you do what you need to do with it. Same experience as with a 'peripheral'.
On Wed, 2010-04-21 at 12:50 -0700, Adam Williamson wrote:
On Wed, 2010-04-21 at 15:40 -0400, Bill Nottingham wrote:
Adam Williamson (awilliam@redhat.com) said:
Given that this is a remote programming tool (as opposed to a tool for *using* the remote), it's likely to be special.
Guessing isn't always a good idea. =) You can't use a Harmony remote without programming it; out of the box they do absolutely nothing. You have to 'program' it for the actual components you want it to control. Concordance does this.
I know what it is. What I mean is that concordance isn't a tool for letting you use the remote as a peripheral with the OS. It's the equivalent of a JTAG programmer.
That's hair-splitting. Ultimately the problem is the same. If you buy a Harmony and you have Windows or OS X, you're fine. It comes with a software disc and instructions on what to do; it's obvious how to set it up. If you use Linux, it's not at all obvious; there is software but you have to find that out and install it yourself. If you just plug it into your system, nothing at all happens, and it's easy to conclude there's no way to use it. It would clearly be much better if, when you plugged in the remote to your Linux system, something notified you that software is available to let you do what you need to do with it. Same experience as with a 'peripheral'.
If that software was even integrated into the desktop, you might have a point. As it is, it integrates in nothing. At least, if the user did a search on the net, they'd get clues, and read documentation about how to use it.
On Fri, 2010-04-23 at 16:06 +0100, Bastien Nocera wrote:
If that software was even integrated into the desktop, you might have a point. As it is, it integrates in nothing. At least, if the user did a search on the net, they'd get clues, and read documentation about how to use it.
It doesn't need to integrate into anything, because that's not how you use it. I do wish people wouldn't comment on this without actually using a Harmony remote =) (or at least it seems like that's what you're doing).
What you do when you get a Harmony is you go to Logitech's website, where there's a big webapp which lets you tell it what devices you have and which should be activated when you're doing various things and all sorts of other details about how the remote should operate. Then you click on a button to upload the settings to your remote, and the site sends you a file.
In Windows, the software Logitech ships on the Harmony disc, that you're supposed to install before going to the website, opens up at this point, tells you to plug the remote into your computer, and uploads the contents of the file to the remote.
What happens at this point if you have Concordance installed is that it does exactly what the Windows software does (only, actually, with a somewhat nicer interface). It opens up automatically - it's associated with the MIME types of the files the webapp sends out - and tells you to plugin the remote, then it programs the remote.
If you DON'T have Concordance installed, what happens is you get a file download in an odd format which Firefox asks you what it should do with, and you get confused.
You're never supposed to launch Concordance manually in normal usage, that's not how the whole system of using a Harmony remote is supposed to work. That's why it, intentionally, does not have a menu entry.
Again, it was only an example! I wasn't expecting to have to write an essay on how it works. Sigh.
(Admittedly the proposed automatic-package-install-on-hardware-connection idea doesn't quite fit in with the Harmony paradigm, but again, it was only one example I thought of off the top of my head, because I happen to be familiar with it).
On Fri, 2010-04-23 at 21:54 +0100, Adam Williamson wrote:
On Fri, 2010-04-23 at 16:06 +0100, Bastien Nocera wrote:
If that software was even integrated into the desktop, you might have a point. As it is, it integrates in nothing. At least, if the user did a search on the net, they'd get clues, and read documentation about how to use it.
It doesn't need to integrate into anything, because that's not how you use it. I do wish people wouldn't comment on this without actually using a Harmony remote =) (or at least it seems like that's what you're doing).
It needs to use a GTK+ UI, follow the HIG, or at least best practices in UI design, use udev for device discovery, etc.
"doesn't need to integrate into anything" seems like a cop-out comment.
It could install whatever is necessary to avoid the "update software" on the Logitech web pages (most likely installing a plugin, rhythmbox has a tiny one we use for iTunes detection).
It's probably better than the software on windows, but it could certainly do with more UI work...
Cheers
PS: I'm talking about the congruity front-end, as concordance doesn't seem to be a UI app.
Heya,
On Wed, Apr 21, 2010 at 3:30 PM, Adam Williamson awilliam@redhat.com wrote: ...
These were simply examples. There's zillions of them. We certainly don't install every package we provide for certain hardware peripherals out of the box, I don't think that can be debated.
And this illustrates one reason why conflating different problems into "package management" isn't really great for producing the best end user experience. An application package, driver package, application plugin package, font package, desktop background package, core os package are all very different things that probably should have different experiences around them (or be entirely invisible). One of the things David was pointing out is that we suck in part because we don't attempt to define what is in the core system and what isn't. He's right. And we should fix that.
The fact that there are zillions of random parts of the Fedora distro is one of the things that makes it not an OS.
Jon
On Wed, Apr 21, 2010 at 7:58 PM, David Zeuthen davidz@redhat.com wrote:
Hi,
(Dropping devel, cross-posting is evil etc. etc.)
On Wed, 2010-04-21 at 09:40 -0400, Colin Walters wrote:
On Wed, Apr 21, 2010 at 7:08 AM, Peter Robinson pbrobinson@gmail.com wrote:
I've spent a little time looking at the hardware side of things and done a basic patch for some of the hardware stuff based on the current rawhide comps file. I've broken it down into network/server/misc for the time being and pushed the print stuff over to its group. More can be done as it was a quick look through. The old hardware-support currently includes all the other groups so there's no real change for current builds overall.
This looks like a good start. I think the way this kind of thing should work in general is that the system detects if you have the hardware, and dynamically installs support for it. We'd need some database mapping things like USB ids to packages. Networking is an exception; we should include as many drivers/tools for networking-related functionality as possible so that the system can be bootstrapped.
Basically: if you have a GPS chip, gypsy gets installed and runs. If you don't, it doesn't.
Don't take this mail the wrong way, but I strongly object to something like that. It is a departure from how things currently work e.g. we install all drivers/software/etc for any gizmo you may or may not plug in. While the current approach certainly represent a cost (bandwidth, diskspace, etc.) I find it highly preferable to some unreliable auto-detection system that is very very hard to get right and comes with its own set of problems (See non-OEM installs of Windows for details).
My view is that there's are a couple of corner cases where doing something like the proposed might work (printer drivers comes to mind) but for core hardware support it is just bound to fail. And it doesn't really buy you anything. Granted, it's an interesting problem to solve and I guess that's why people keep advocating such a system. But for a free OS developed in a centralized way (for better or worse) it's pretty much just fail city.
(FWIW, here's an idea: I think we should work towards everyone getting everyone the same goddamn OS image (which is thoroughly tested, QA'ed etc etc) instead of making the current time-space combinatorics thing we're doing right now even harder and more complex.)
+1
Hardware should JUST WORK ... anything else is just failure on our side.
And when we have to choose between better user experience (hardware just work) or save some disk space (which is cheap anyway) the choice is obvious imho.
On Wed, 2010-04-21 at 09:40 -0400, Colin Walters wrote:
On Wed, Apr 21, 2010 at 7:08 AM, Peter Robinson pbrobinson@gmail.com wrote:
I've spent a little time looking at the hardware side of things and done a basic patch for some of the hardware stuff based on the current rawhide comps file. I've broken it down into network/server/misc for the time being and pushed the print stuff over to its group. More can be done as it was a quick look through. The old hardware-support currently includes all the other groups so there's no real change for current builds overall.
This looks like a good start. I think the way this kind of thing should work in general is that the system detects if you have the hardware, and dynamically installs support for it. We'd need some database mapping things like USB ids to packages. Networking is an exception; we should include as many drivers/tools for networking-related functionality as possible so that the system can be bootstrapped.
Basically: if you have a GPS chip, gypsy gets installed and runs. If you don't, it doesn't.
Most of the GPS devices you won't be able to detect. 99% of the Bluetooth ones don't use the correct device class because it was too new, most of the serial/USB ones will just show up as serial ports that you would have no idea what's behind them.
All that to save 120k of installed space. If we're going to go down that route, we might as well split out the iPod support in Rhythmbox, or the PulseAudio Bluetooth support.
desktop@lists.fedoraproject.org