Bug#563003: xserver-xorg-video-intel: New KMS method in experimental is not upstream recommended
On Wed, Dec 30, 2009 at 2:44 PM, Julien Cristau <jcristau@debian.org> wrote:
> On Wed, Dec 30, 2009 at 14:00:51 -0600, Jason Clinton wrote:
> Still no evidence for your assertion that this approach isn't
> recommended.
Fedora, for all intents and purposes, is authoritative on this matter
since keithp and anholt both work tightly and rather exclusively
(unfortunately) with Fedora's Adam Jackson on developing policy and
implementing features specifically related to the standardization of
KMS across all drivers; Red Hat is, for better or worse, doing almost
all of the heavy lifting in radeon and nouveau. That is why I pointed
to Fedora as evidence: you *need* to download and trying out the
competition, especially when the competition is considered the
canonical practice on the mater. (I don't understand why you are
arguing this is not the case.)
>> Regardless, your method is not necessarily
>> incompatible with what I suggested. Indeed, an initramfs system which
>> does copy in the modprobe configuration file is quite compatible with
>> your method. It just doesn't work in Debian because that is not what
>> was added to initramfs-tools and it's unnecessary in Fedora and Ubuntu
>> because of the kernel module parameter that you pointed to. If
>> initramfs-tools were extended to copy-in and then honor the modprobe
>> configuration data, then "video=i915" would be sufficient for invoking
>> KMS (that is, "video=i915:modeset=1" would be unneeded.)
>>
> The modprobe configuration data *is* copied and honored by
> initramfs-tools.
However, the data is currently not utilized in the video=i915 case; I
just tried it. (Perhaps a bug, I know.)
>> I'm not saying that this would be the preferred method (indeed you are
>> still having to modify the kernel line) but it would be one way. IMHO,
>> "video=i915:modeset=1" is the most sane method as long as the kernel
>> parameter is to remain as it is currently in Debian.
>>
>> Either way, it *must* be loaded in the initramfs to preserve VT1 which
>> is what this bug is about.
>>
> That can also be fixed by udev loading i915 when it loads the rest of the
> drivers at the start of the boot. No need to change the kernel command
> line then.
Indeed that would help alleviate the problem but you would be
precluding the utilization of usplash with a properly configured Intel
framebuffer since udev is triggered after the root filesystem is
mounted. Why are you so opposed to the usage of initramfs loading of
this module when it is the practice everywhere else?
It's mind-numbing to me that *right* *now* the initramfs-tools are
copying the i915 module in to the initramfs due to no action taken on
your part yet you won't support actually loading them there.
Reply to: