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 th
[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-fwcutte
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 th
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 b
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 ful
[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 po
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 deb
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 disco
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 2
[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
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 m
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
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 boot.
13 matches
Mail list logo
