From: "Michel Dänzer" <michel@daenzer.net>
To: Jon Smirl <jonsmirl@yahoo.com>
Cc: linux-fbdev-devel@lists.sourceforge.net, dri-devel@lists.sourceforge.net
Subject: Re: Current discussion about the future of free software graphics
Date: Thu, 13 May 2004 12:39:06 +0200 [thread overview]
Message-ID: <1084444744.3032.93.camel@thor.asgaard.local> (raw)
In-Reply-To: <20040512033045.16034.qmail@web14921.mail.yahoo.com>
On Wed, 2004-05-12 at 05:30, Jon Smirl wrote:
> If everyone will please read Benh's original post describing this... Ben and I
> had been emailing on this topic before he wrote this.
>
> --- Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > I agree with the idea of moving the EDID decoding & mode selection to
> > userland. In this regard, though, I beleive we should aim toward some
> > simple library that sits with the kernel, eventually distributed with
> > the kernel tree, to live in initramfs optionally since it may be
> > required to even get a console at boot (which is fine, initramfs is
> > available early). The video cards themselves have PCI drivers that can
> > "trigger" detection by the library via hotplug, the library could manage
> > things like persistent configuration, either separate desktops or
> > geometry of a complex desktop, etc... and eventually notification of
> > userland clients of mode changes.
> >
> > One reason for that is lots of monitors lie about their capabilities in
> > their EDID block, so we want "override" files.
> >
> > The kernel driver in this case doesn't need to be that much different
> > than the current fbdev's though, except that we want to move the HW
> > access for graphics commands to the kernel too, which basically turns
> > into merging the DRI driver and the fbdev. There is no need, I think, to
> > re-invent the wheel from scratch here, it would be a lot more realistic
> > to build on top of those existing pieces.
>
> What this is saying is that very early in the boot process the graphics driver
> will be initialized. At this point it will generate a hotplug event. This event
> will be handled by an app and lib that live in initramfs. This is not saying
> that mode-setting will be delayed until normal user space starts.
Sure, because Ben doesn't talk about moving mode-setting to userland at
all AFAICT. :)
> I've already built a very messy prototype by moving the existing fbdev
> code to user space and it works just fine.
Maybe if others could play with this prototype...
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
--
next prev parent reply other threads:[~2004-05-13 10:39 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-11 18:09 Current discussion about the future of free software graphics sottek
2004-05-11 19:55 ` James Simmons
2004-05-11 20:46 ` Ian Romanick
2004-05-12 3:30 ` Jon Smirl
2004-05-12 14:41 ` Richard Smith
2004-05-12 17:56 ` James Simmons
2004-05-12 18:56 ` Geert Uytterhoeven
2004-05-12 19:11 ` James Simmons
2004-05-12 19:40 ` Geert Uytterhoeven
2004-05-12 21:09 ` James Simmons
2004-05-12 19:23 ` Richard Smith
2004-05-12 20:45 ` Richard Smith
2004-05-12 16:45 ` James Simmons
2004-05-12 19:00 ` Geert Uytterhoeven
2004-05-12 22:45 ` Nicolas Souchu
2004-05-13 10:39 ` Michel Dänzer [this message]
2004-05-12 8:48 ` [Dri-devel] " Keith Whitwell
2004-05-12 17:09 ` James Simmons
2004-05-13 3:32 ` Keith Packard
2004-05-12 14:14 ` Alan Cox
2004-05-11 20:07 ` Geert Uytterhoeven
2004-05-11 23:10 ` James Simmons
2004-05-11 23:15 ` Nicolas Souchu
2004-05-12 13:34 ` Michel Dänzer
2004-05-12 13:54 ` Egbert Eich
-- strict thread matches above, loose matches on Subject: below --
2004-05-11 0:11 [Linux-fbdev-devel] " Sottek, Matthew J
2004-05-11 2:20 ` Adam Jackson
[not found] ` <200405102120.48640.ajax-TAsg7VrFCGc@public.gmane.org>
2004-05-11 13:24 ` Michel Dänzer
[not found] <1084205711.804.43.camel@thor.asgaard.local>
2004-05-10 23:45 ` James Simmons
2004-05-10 16:15 Michel Dänzer
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=1084444744.3032.93.camel@thor.asgaard.local \
--to=michel@daenzer.net \
--cc=dri-devel@lists.sourceforge.net \
--cc=jonsmirl@yahoo.com \
--cc=linux-fbdev-devel@lists.sourceforge.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.