Bug#732692: loading radeonkms results in unusable screen
Hi Steven,
I'm glad you brought this up... please bear with my reordering of your
reply, which makes it easier to make my point:
On 24/12/2013 14:33, Steven Chamberlain wrote:
> I seem to think the patch to the Xorg driver (#732514) is the riskiest
> change, at which point radeon will stop working.
Well, up to this point autoloading was not operative, in part due to #732514
but also due to missing linker.hints in kernel (#684595).
Fixing both these bugs means the kernel will attempt to satisfy userland's
demands of a fully working "radeonkms.ko" module. Since we don't provide
that, this situation has the potential of exposing new bugs.
But I don't think relying on bugs to mitigate the risk is necessary. Fixing
them puts the kernel in control, and then there are many other ways to achieve
the same thing. Note that only when userland meets these two conditions:
1- Is able to load "radeonkms" module.
2- Is able to detect modesetting sysctls after loading the module.
then it will expect working KMS support. However, it is up to the kernel
wether each condition is met:
1- The kernel build system still builds "radeonkms" even if the firmware
was disabled.
2- The radeonkms module still enables the sysctls even if firmware load
failed.
My proposal was to disable #1 (i.e. remove the module). However if the
module is still useful there are many ways in which #2 can be changed to
adhere to our needs.
For example, we could disable the sysctls every time firmware load failed,
or we could include a whitelist of drivers which still work despite that.
Or we could use a blacklist instead, and enable the sysctls unless firmware
failed _and_ the driver is known to generate trouble without it.
We can really fine-tune to any level we want. The only limit is the time
required to implement and test, debug, etc.
> If we're not doing any automatic module loading yet, I don't think there
> will be any functional change from doing this?
It would preserve the status quo, since the same upload was targeted to
fix #684595 (linker.hints bug).
However if we need more time to make a decision, we could just postpone the
fix for #684595 just to get -RC3 out of the door without delay.
>> Is there a case for providing an incomplete version (i.e. without firmware)?
>
> It has the capability to load firmware, though. So it potentially
> allows for packaging just the microcode, just as firmware-linux-nonfree
> does for Radeon KMS on Linux.
Well no, not really. I've seen previous discussion assuming this is the case,
but in fact the firmware_* interfaces don't implement anything similar, and
upstream favours embedding firmware in dedicated modules (e.g. radeonkmsfw).
They even have support in the build system to handle this in the least
painful way (see sys/modules/drm2/radeonkmsfw/*/Makefile for an example).
It is difficult for us to make a case to upstream that the "Linux way" is
better. I already persuaded them to provide the choice in build system on
whether to provide sourceless firmware or not (this resulted in
-DWITHOUT_SOURCELESS make knob which has been tremendously helpful to
reducing the sys/modules/Makefile delta). What do they gain by moving the
blobs off *fw modules? AFAICS, they're just losing the features provided
by the module linker (e.g. versioned dependencies).
> I hope I will have some time now to test this,
Sure. Since this matter is quite complicated, and probably needs a lot more
careful thought and testing, how about we just preserve the status quo in
-RC3 upload by putting #684595 on hold? Then #732514 has no effect (except
to kfreebsd-downloader users, which is fine IMHO), and we have time to
think this through.
--
Robert Millan
Reply to: