On Mon, Aug 06, 2007 at 06:39:06PM +0200, Petter Reinholdtsen wrote:
Today I made a small step further on my plan for better hardware
support in Debian. I added support in discover version 2.1.2-1 for
calling module-assistant in discover-pkginstall, and fixed a few
long-standing bugs in the
[Jérémy Bobbio]
Will that work for madwifi (Wi-Fi cards based on the Atheros
chipset)?
If there are source packages with this driver in Debian, and someone
get the required information into discover-data, yes.
On a closely related matter, could your infrastructure install
bcm43xx-fwcutter
On Mon, Aug 06, 2007 at 06:39:06PM +0200, Petter Reinholdtsen wrote:
Today I made a small step further on my plan for better hardware
support in Debian. I added support in discover version 2.1.2-1 for
calling module-assistant in discover-pkginstall, and fixed a few
long-standing bugs in the
Today I made a small step further on my plan for better hardware
support in Debian. I added support in discover version 2.1.2-1 for
calling module-assistant in discover-pkginstall, and fixed a few
long-standing bugs in the debconf handling in that script.
With this change in place, calling
Petter Reinholdtsen [EMAIL PROTECTED] writes:
Not very many kernel module source packages are recognized by the
discover-data package at the moment. Two devices using the
qla2x00-source package is all there is at the moment. The problem
with maintaining the mapping from hardware to debian
[Otavio Salvador]
I think it can be improved. Let me explain my idea:
If we build the module that we want to add on the database and write a
small script that uses modules.alias file updated with it we can write
the database will full module knownledge available. This would all
make
Petter Reinholdtsen [EMAIL PROTECTED] writes:
[Otavio Salvador]
I think it can be improved. Let me explain my idea:
If we build the module that we want to add on the database and write a
small script that uses modules.alias file updated with it we can write
the database will full module
Petter Reinholdtsen [EMAIL PROTECTED] writes:
[Otavio Salvador]
Can you please elaborate a little more how do you intend to do that?
I personally wouldn't like to have my system with gcc and like,
needed to build the module, so would be nice if we might purge those
packages after building
In general it is a setup I would support, but only for things that are
rock solid. I mean only when you can be 100% sure that all (or at least a
vast majority) owners of the hardware will want that feature _and_ that
the feature will really work on all hardware it is installed on.
On Saturday
Op 21-04-2007 om 12:56 schreef Petter Reinholdtsen:
During installation, and afterwards, there are a few things that could
be improved regarding hardware detection. Here are some ideas I have
on the topic.
This comment is only on one idea.
Third, some hardware is supported by kernel
[Geert Stappers]
That automatic build of driver source into kernel module,
how automatic will that be?
What will the effect on the boot time?
Not sure. I see two options, to make sure the kernel modules are
still available:
- compile the source with the new kernel when the new kernel is
During installation, and afterwards, there are a few things that could
be improved regarding hardware detection. Here are some ideas I have
on the topic.
At the moment, we have a system in place to load kernel modules
depending on the PCI (and USB) hardware detected during installation
and
Petter Reinholdtsen [EMAIL PROTECTED] writes:
[...]
Hardware (PCI, DMI, CPU, USB, etc) mapped do one or more of
- Kernel module name
- X driver name
About X driver would be nice to have fallback options. For example, if
the user has the non-free driver for nvidia this should be
13 matches
Mail list logo
