public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: CONFIG_DRM_LEGACY
Date: Tue, 12 Jul 2022 12:22:24 +0200	[thread overview]
Message-ID: <17F5F871-D0D1-4AA1-B830-5E500DED394F@ipfire.org> (raw)
In-Reply-To: <4f90fef9-65d4-d645-09d0-8bb53d626807@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 2561 bytes --]

Hello,

> On 10 Jul 2022, at 13:12, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi Peter,
> 
> On 10/07/2022 12:00, Peter Müller wrote:
>> Hello development folks,
>> 
>> recently, it has been flagged to me that we ship our kernels with CONFIG_DRM_LEGACY enabled.
> 
> Looking through Arch Linux I see that since Kernel 5.14 this option has been present. Some OS's have it enabled and some have it disabled. Arch Linux is in the disabled camp and they had already removed many of the DRM based drivers from their core repository.
> 
> The result of that is that anyone needing to use old DRM based video cards such as Nvidia 340 and Mach64DRM have to now build the video driver themselves  but also build their own kernel to set this parameter.
> 
>> The documentation to this reads:
>> 
>>> Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
>>> APIs to user-space, which can be used to circumvent access
>>> restrictions and other security measures. For backwards compatibility
>>> those drivers are still available, but their use is highly
>>> inadvisable and might harm your system.
>>> 
>>> You are recommended to use the safe modeset-only drivers instead, and
>>> perform 3D emulation in user-space.
>>> 
>>> Unless you have strong reasons to go rogue, say "N".
>> Because of the kernel released on July 7 and its fixes to ASIX USB-to-Ethernet adapters, I
>> am currently working on that sector of IPFire 2.x anyway. Unless somebody of you can recall
>> why we really need to have CONFIG_DRM_LEGACY enabled, I would submit a patch disabling it -
>> its documentation does not inspire confidence at all. :-)
> 
> I had a similar feeling when I read about it.
> 
> I would suppose the question would be how many of the IPFire users use older DRM based video cards on their IPFire machines.
> 
> Does IPFire include the drivers for these DRM based video cards? If not then making the config disabled shouldn't give any problem.

Currently nobody is using any card with DRM. We have all modules blacklisted in favour of framebuffer.

I would prefer to change that, use DRM, and drop framebuffer.

Since we do not need to support all those DRM features and all cards and because all cards should support come VESA-compatibility mode, this should be safe to be disabled.

I suppose Arne is the best person to comment on this.

-Michael

> 
> That's my input from having a quick search on this topic.
> 
> Regards,
> 
> Adolf.
> 
>> Thanks, and best regards,
>> Peter Müller


      reply	other threads:[~2022-07-12 10:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-10 10:00 CONFIG_DRM_LEGACY Peter Müller
2022-07-10 11:12 ` CONFIG_DRM_LEGACY Adolf Belka
2022-07-12 10:22   ` Michael Tremer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17F5F871-D0D1-4AA1-B830-5E500DED394F@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox