[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <21d7e9970705210927s1454dc5ete89005715253f4b7@mail.gmail.com>
Date: Mon, 21 May 2007 17:27:15 +0100
From: "Dave Airlie" <airlied@...il.com>
To: "Jon Smirl" <jonsmirl@...il.com>
Cc: "Jesse Barnes" <jbarnes@...tuousgeek.org>,
"Helge Hafting" <helge.hafting@...el.hist.no>,
"Jesse Barnes" <jesse.barnes@...el.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC] enhancing the kernel's graphics subsystem
>
> What about modifying the existing fbdev API? You could start with one
> fbdev device per CRTC and then add a new IOCTL to control the output
> device. I haven't seen anything yet that justifies abandoning the
> existing fbdev API.
Then you can't aribtrate properly output hooking is a root level
thing, you cannot allow the user in multiseat to just pick his own
outputs, if you claim to want a truly flexible interfaces, also the
crtc->output mappings aren't always simple, there are limitations on
most hw about which crtc can map to which output and when you can
clone etc.. putting policy for this stuff in-kernel would heavily
restrict what the user can do...
At the moment, you can with a small userspace app add two
framebuffers, link them to crtcs and link those to outputs, then users
can use /dev/fb/* to do what they need, we haven't linked up mode
setting so that fbset works yet I don't think, but if people really
wanted that we could probably do so... so far we just have enough
fbdev to support fbcon...
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/
Powered by blists - more mailing lists