linux-kernel - Re: Proposal for a low-level Linux display framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADnq5_OYLwPPAQOAG3N1rQRZ49JZTKpXVVHePPXFA-jR-a9wHw@mail.gmail.com>
Date:	Sat, 17 Sep 2011 17:25:12 -0400
From:	Alex Deucher <alexdeucher@...il.com>
To:	Florian Tobias Schandinat <FlorianSchandinat@....de>
Cc:	Dave Airlie <airlied@...il.com>, linux-fbdev@...r.kernel.org,
	linaro-dev@...ts.linaro.org, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, Archit Taneja <archit@...com>,
	Rob Clark <rob@...com>
Subject: Re: Proposal for a low-level Linux display framework

On Sat, Sep 17, 2011 at 3:06 PM, Florian Tobias Schandinat
<FlorianSchandinat@....de> wrote:
> On 09/17/2011 06:23 PM, Dave Airlie wrote:
>>>
>>> Is it? Well, okay, I don't want to use any acceleration that can crash my
>>> machine, where can I select it, preferably as compile time option? I didn't find
>>> such a thing for Intel or Radeon. Don't say, I should rely on userspace here or
>>> use fbdev for this.
>>
>> Just tell the X driver to not use acceleration, and it you won't get
>> any acceleration used, then you get complete stability. If a driver
>> writer wants to turn off all accel in the kernel driver, it can, its
>> not an option we've bothered with for intel or radeon since it really
>> makes no sense. To put it simply you don't really seem to understand
>> the driver model around KMS. If no userspace app uses acceleration
>> then no acceleration features will magically happen. If you want to
>> write a simple app against the KMS API like plymouth you can now use
>> the dumb ioctls to create and map a buffer that can be made into a
>> framebuffer. Also you get hw cursors + modesetting.
>
> Again, you seem to not understand my reasoning. The "if" is the problem, it's
> the kernels job to ensure stability. Allowing the userspace to decide whether it
> crashes my machine is not acceptable to me.
> I do not claim that it is impossible to write a KMS driver in a way that it does
> not crash, but it seems more difficult than writing an fbdev driver.
>

It's perfectly valid to write a KMS DRM driver that doesn't support
acceleration in which case it will be just as "stable" as a fbdev
driver.  In fact on modern hardware it's probably easier to write a
KMS DRM driver than a fbdev driver because the API and internal
abstractions match the hardware better.  If you have hardware with 4
display controllers, 2 DACs, a TMDS encoder, and a DP encoder how do
you decide which combination of components and modes to light up at
boot using fbdev?

Alternatively, if you wanted to support acceleration as well, you can
add a module option to force acceleration off at the kernel level
rather than from userspace.  It's trivial.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/