linux-kernel - Re: [RFC] enhancing the kernel's graphics subsystem

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: <21d7e9970705221025r2f798dc5x310947db040c6521@mail.gmail.com>
Date:	Tue, 22 May 2007 18:25:05 +0100
From:	"Dave Airlie" <airlied@...il.com>
To:	"Jon Smirl" <jonsmirl@...il.com>
Cc:	"Jesse Barnes" <jbarnes@...tuousgeek.org>,
	"Jeff Garzik" <jeff@...zik.org>,
	"Jesse Barnes" <jesse.barnes@...el.com>,
	linux-kernel@...r.kernel.org,
	"Antonino A. Daplas" <adaplas@...il.com>
Subject: Re: [RFC] enhancing the kernel's graphics subsystem

> These are not isolated problems. Linux needs a properly designed
> graphics subsystem. One way to achieve that is to design it all on
> paper first so that we can try and locate the interactions between
> modules. For example the current mode setting design is definitely
> broken for multi-seat support, that's because you didn't take that
> feature into account when writing the code.

No it isn't the code Jesse posted can handle multi-seat fine in the
areas that it makes sense as we've pointed out to you you cannot just
divide a GPU up into two head and not have the users interfere with
each other, reprogramming modes on multiple crtcs/outputs and setting
up memory bandwidth calculations requires the driver to do things that
will potentially disrupt the other user, in most cases setting a mode
on a head requires turning off all devices on the card first and
switching them back on in a certain order, this is usually due to
clocking interactions,

We can provide two fb interfaces for users wanting to do what you
want, we then need to fix the VT subsystem on top of that, however for
most of our users (like 95% at least) we want to support X as best we
can, and that is where the energy will be placed initially, reducing
the number of mode changes on startup along with suspend/resume for
users is a major goal of this work.

> Putting a small module into the kernel first with a random API, then
> try and build the next module is not a good development path. It is
> better to design all of the modules on paper and then work backwards
> to the API the first module needs.  Even better would be to get the
> whole subsystem working before including it in the kernel. Once these
> exposed APIs go it, it is impossible to get them out. We need to try
> and make sure that they are correct to begin with.

Fine, but nobody has succeded at this, because the effort of doing it
this way is not incrementally developed, we are not designing DX10, we
are improving Linux graphics one step at a time.

>
> You need to take into account that you are proposing the replacement
> of an existing subsystem, not the initial inclusion of a virgin
> system. Putting your code in as is does make the X server happy, but
> it is not solving all of the known problems with the existing graphics
> subsystem. If you just want to make to X server happy it would be
> better to extend the existing fbdev API and not try and replace the
> subsystem.

The thing is we need integration with memory management, the memory
management is in the drm as it is complicated and the work is done, I
know you aren't even reading this sentence at this point.

Dave.
-
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/