Hardware out-of-the-box options?

Message

moult · Post by **moult** » Wed Nov 25, 2009 4:03 am

Obviously the main pull of Gentoo lies in its flexibility and ability to configure everything. The side effect of this is that everything has to be configured manually. This isn't a problem with software and I would and I'm sure many would agree that this should be seen as a feature.

However with hardware I find it pretty rare that people want to tweak it. It's much more common that people simply want peripheral X or Y to work without problems. Other distributions support a pretty much plug and play if there is support for it. On Gentoo even if there is support, there is still a lengthy "bah! why is it only working sporadically?" or half-supported setups. How hard would it be to create perhaps a set of packages which have scripts and so on which'll automatically do all that configuring for you? (obviously assuming you build the kernel support in yourself).

It won't add to the "bulk" of the system as it'll simply be another package in portage - installing it is optional, using it is optional, and of course you still have full control of what goes in and out of your kernel. At the same time, I'm sure if developed properly it could become an invaluable tool to other distributions?

I really don't see a disadvantage- quite honestly I don't hear people saying "No - I don't want this option, I want to force myself to accomplish hardware support in the most difficult way possible".

What do you guys think?

anonybosh · Post by **anonybosh** » Wed Nov 25, 2009 4:17 am

Sounds like a great idea to me.
I only wonder how easy it would be to maintain such ebuilds, as I would venture to guess that using the setups created by say the Ubutntu project, are downstream of the source project. Might cause some problems, but I don't really know.
Would it be enough to have a standard USE flag or would it be better to have such ebuilds in their own part of the portage tree?

Genone · Post by **Genone** » Thu Nov 26, 2009 2:51 pm

Do you have any concrete examples where it's clearly a distribution issue rather than an upstream issue?
I strongly suggest to identify the problem and its causes first before starting to work on solutions.

Jaglover · Post by **Jaglover** » Thu Nov 26, 2009 3:25 pm

I really don't see a disadvantage- quite honestly I don't hear people saying "No - I don't want this option, I want to force myself to accomplish hardware support in the most difficult way possible".

I've to admit I don't get your point. You agree Gentoo is about software customization, hardware is handled by software indeed. Of course I want to configure the hardware support myself. I wouldn't say there is "most difficult way possible", IMHO there is just one way, difficult or not depends on user accomplishing the task.
I do remember pre-PnP times when one had to set jumpers to set base address and IRQ, and then configure the driver to access the device using those parameters. Otherwise it just didn't work. I kind of miss the clarity we had back then.

moult · Post by **moult** » Thu Nov 26, 2009 4:14 pm

Jaglover wrote:
I really don't see a disadvantage- quite honestly I don't hear people saying "No - I don't want this option, I want to force myself to accomplish hardware support in the most difficult way possible".
I've to admit I don't get your point. You agree Gentoo is about software customization, hardware is handled by software indeed. Of course I want to configure the hardware support myself. I wouldn't say there is "most difficult way possible", IMHO there is just one way, difficult or not depends on user accomplishing the task.
I do remember pre-PnP times when one had to set jumpers to set base address and IRQ, and then configure the driver to access the device using those parameters. Otherwise it just didn't work. I kind of miss the clarity we had back then.

True, hardware is handled by software. However the difference is that with hardware people want it to "work". Hardware either works or it doesn't. Whether or not they want to tweak it later on "how" it works is irrelevant. The point is getting it to work in the first place.

Allow me to use two analogies - the first is portage. You can customise the package to any amount of detail - remove useflags, change compiler options etc, but the fact remains that it compiles in the first place. If you want, you can edit the source code to have extreme control over it - and of course, if you decide you want full control over everything, you can create your own ebuilds, or compile it outside portage. Similarly, you want your hardware to work in the first place - but there's nothing stopping you from tweaking it later on. Of course if you choose to do it manually there's nothing stopping you either.

The second analogy is much more relevant - genkernel. I'm not a genkernel user but I do see its benefits. This is very much like that.

I hope that clarified my point. The objective is not to hide everything from the user, but instead to streamline the process of getting your hardware to work. Such a system could remove the need to have to search a good deal of websites to see if your driver is compatible, see what bugs you might encounter with your hardware, what drivers you need enabled, which configuration files do what and what variables you might need to set ... it's easier to maintain instead of a collection of HOWTOs and wikis online, it can be kept constantly up to date, and of course keep the flexibility for whatever a Gentoo user wants. One thing I do envision is a personalised handbook for your hardware (apologies if highly unrealistic imagination).

Genone wrote:Do you have any concrete examples where it's clearly a distribution issue rather than an upstream issue?
I strongly suggest to identify the problem and its causes first before starting to work on solutions.

I'm sorry but I have to admit that I'm know very little about hardware. However I do know that if I plug in a Ubuntu (don't scream) CD my wifi, webcam, and external speakers work Just Like That (tm). Gentoo, even after following some guides things are a bit wonky. A debugging process via an online search, IRC or forum provides a solution sometimes, but that solution is outside the scope of the article that I followed to set it up. Therefore this shows that there are things which can be improved on.

What I can suggest is:
1) Make a list of hardware things we might be able to support through this.
2) Identify the "installation" for each of these hardwares. Eg: 1) compile support in kernel [therefore identify drivers], 2) start editing configuration files [which configuration files do what] 3) useful config variables 4) ways to test if it works 5) troubleshooting [linked to the testing stage] 6) alternatives 7) existing known bugs 8 ) further tweaking possibilities
3) Identify which of these "installation" steps can be automated or be made more streamlined and how- eg: through scripts, local howtos, perhaps a knowledge base on hardware compatibility

I would like to stress that obscurity of the process is not an objective. This, for example, is not what I have in mind:

Code: Select all

localhost ~ $ hardwareconfig --justconfigit
Configuring webcam ... done!

I'm just throwing a few ideas around

Jaglover · Post by **Jaglover** » Thu Nov 26, 2009 4:34 pm

You can run lspci -k from Ubuntu to see what driver is in use, there is plenty of information in /usr/src/linux/Documentation. Well, I acknowledge people are different, I for one never had a problem with hardware (as long as Linux is supported).

yngwin · Post by **yngwin** » Thu Nov 26, 2009 9:56 pm

You still describe things in vague terms. Give concrete examples please.