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]

Date:	Mon, 21 May 2007 08:57:44 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Helge Hafting <helge.hafting@...el.hist.no>
Cc:	Dave Airlie <airlied@...il.com>, Jon Smirl <jonsmirl@...izon.net>,
	Jesse Barnes <jesse.barnes@...el.com>, jonsmirl@...il.com,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] enhancing the kernel's graphics subsystem

On Monday, May 21, 2007, Helge Hafting wrote:
> >> > TThe problem with that is the concept of heads is flawed... there
> >> > is in reality no such
> >> > thing, you have crtcs and outputs, no heads. So any attempt to
> >> > enforce the head concept involves putting policy into the kernel,
> >> > as if I have 3 outputs but 2 crtcs how do I decide the mappings
> >> > without the admin telling the kernel,
> >>
> >> Solution:
> >> One device per crtc. You can then have two users, running consoles
> >> or xservers on their crtcs, without having to involve root.
> >
> > Thats pretty much what the code does, but you still are putting a
> > certain amount of policy in the kernel...
>
> What policy would that be?
> The mapping is set by root from userspace, not by the kernel.
> The same for ownership to crtc devices. The kernel may have to
> provide some default so "init=/bin/sh" will work, that's all.

The policy of mapping outputs to CRTCs.  Like Dave said, you may have 
several outputs but only one or two CRTCs, with limitations on how they 
can be routed.  So doing "one device per CRTC" isn't quite enough, you 
also have to choose an initial output setup.  But like you say this could 
be changed at boot time.

> Sure.  Not multiseat by default, as the kernel can't know which output
> goes with which keyboard. All I want it a system that allows
> multiseat for those that care to set it up.

Sure, and like I mentioned to Jon in another mail, a decent multiseat setup 
is possible with these interfaces, albeit with a userlevel graphics daemon 
to arbitrate what the CRTC->output mappings are and to coordinate access 
to the hw if needed.

So really, I think the interfaces posted here will do what you want.  Maybe 
you can take a closer look and make sure?

Thanks,
Jesse
-
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/