[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Hardware detection



Hi

On 2016-01-07, Stephan Foley wrote:
> Hello, I am working on a Fluxbox Debian Pure Blend:
> 
> https://wiki.debian.org/FluxBox/Blend
> 
> Currently, I am going to use discover, mdetect and read-edid for
> hardware discovery but found in the repos hwinfo which is used by
> Debian Edu and was wondering if this is a better tool. Description
> follows:
[...]

As someone working on Debian derived live systems since the earlier
kernel 2.4 days, I wonder why you think to need any of those on a 
modern linux system at all?

linux >= 2.6, udev and kmod do a great job to probe all 
auto-discoverable devices on their own. The things they miss either 
can't be detected automatically or at least not in a safe way. Neither
of which are typically found on systems supported by Debian systems
whose primary purpose is running/ showcasing/ using a window manager.
The i586/ i686 cutoff mostly prevents you from having to discover 
ISA devices or even weirder legacy system buses - and on embedded 
architectures with SDIO, similar non-discoverable buses and board 
specific boot procedures, you have bigger problems (e.g. getting FOSS 
display driver support) than anything discover/ mdetect/ hwinfo can 
help you with.

Regarding read-edid, why?! X.org does a pretty good job detecting your
screen, its native resolution and your common input devices these days
(I'm too lazy to check for the exact version, but for a few years 
already). The only time you might want to override the auto-detected
settings, is typically when automatic detection doesn't work (broken
EDID, weird setups, etc. - but this usually means older than ~15-20 
year old CRTs), in which case read-edid isn't very likely to help you 
either. Complex multi-screen setups just aren't something you can
detect, as nothing will tell you which monitor is left/ right/ top/
bottom - so the only thing you can do there is sticking to X.org's
defaults (clone) and providing an easy way to do xrandr based runtime
configuration (a feature typically covered by modern desktop 
environments).

These days, live systems basically need help (beyond the default 
features provided by a normal Linux/ Debian installation; the situation
slightly differs for kfreebsd or probably hurd) in two areas[0]:
- setting up a network connection (again, the kernel probes the required
  modules quite well, the problem is just a policy decision. Find 'the'
  network interface with a link beat and run a dhcp client, if that 
  doesn't help, the user needs to configure it manually anyways - same 
  for encrypted wlan, wwan, etc.) - and providing firmware blobs, if 
  needed.
- generating a fstab (and even this is largely optional these days, 
  considering today's RAM sizes, auto-discovering an existing swap isn't
  as critical as in the days of yore, the other disks/ partitions are
  typically handled quite well with udisk2 and policykit in the typical
  desktop environments, although probably not using fluxbox).

plus the things that aren't hardware dependent at all, like:
- finding~ and cooking the rootfs to appear writable
- forgetting stale state ((re-)generating machine IDs, clearing sshd keys,
  etc.)[1]
- setting up live users/ preseeding[2] a sane configuration environment
- intercepting reboot/ halt and properly shutting down the live 
  environment
- locales/ i18n/ keymaps
- ...

discover, hwinfo, hwdetect, kudzu, read-edid had their days of fame (or 
rather, they were a painful necessity), but at least on semi-modern linux
systems they are pretty much obsolete for a couple of years already for 
anything resembling a remotely 'normal' system (anything with VGA/ DVI/ 
HDMI/ DP, PCI(e), USB and BIOS|UEFI with ACPI). And at least for the non 
UEFI/ACPI armhf/ arm64 world, either of those tools come way too late (as 
you need a SOC/ board specific bootloader and configure it to use the 
proper dtb; beyond that, kernel/ udev should just work as well for most 
auto-detectable devices there as well).

Regarding "hardware detection", there typically is only one distant domain
which could need some further refinements - namely helping the user to
find missing firmware images for their devices (preventing them from just
working out of the box, aka welcome the non-free blobbyness of the real 
world) or identifying additional packages you might not want to preinstall,
but which are nevertheless useful (only) in combination with certain 
hardware (e.g. sane, if you have a scanner, fprintd if a fingerprint reader
is present, something like this) - isenkram is supposed to cover this.

You haven't really revealed if the target of your pure blend is an 
installed system or a live environment (the wiki page and your mail 
slightly tend towards a live system, but neither provide a definitive
answer), but in neither case it should be much of a concern how to
detect hardware (as that's either solved by d-i or your live framework 
in a desktop/ WM agnostic way) for you as blend maintainer. If you do,
you're quickly leaving the pure-blend domain and venture into the 
derivatives land[3]. 

You'll probably find an audience with more specific knowledge in these
particular areas on the debian-derivatives@lists.debian.org and 
debian-live@lists.debian.org lists.

Regards
	Stefan Lippers-Hollmann

[0]	yes, I'm simplifying this a bit, but the days of black magic
	and voodoo are fortunately in the distant past and you don't
	need to do too much, to make a normal linux installation 
	"portable".
[1]	this is basically the only problem where Debian packages could
	improve the situation for image based replication and 
	distribution approaches	massively, by implementing a global 
	"factory reset" flag and removing (preventing it from entering
	the image)/ regenerating (on boot) all unique state.
[2]	on a pure-blend, the pre-seeding should be almost non-existent
[3]	unless you start to wear both hats, pure-blend- and live 
	framework maintainer/ patch contributor, of course.

Attachment: pgppOeqHoVA3x.pgp
Description: Digitale Signatur von OpenPGP


Reply to: