From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Kronos <kronos@people.it>
Cc: Jon Smirl <jonsmirl@yahoo.com>,
fb-devel <linux-fbdev-devel@lists.sourceforge.net>,
DRI Devel <dri-devel@lists.sourceforge.net>
Subject: Re: [Linux-fbdev-devel] OLS and console rearchitecture
Date: Wed, 28 Jul 2004 23:57:59 +0100 [thread overview]
Message-ID: <1091055478.31913.7.camel@localhost.localdomain> (raw)
In-Reply-To: <20040728213102.GB26087@dreamland.darkstar.lan>
On Mer, 2004-07-28 at 22:31, Kronos wrote:
> There was a thread on acpi-devel about POSTing VGA ROM after resume:
>
> http://marc.theaimsgroup.com/?l=acpi4linux&m=109023076427394&w=2
>
> The code does a real mode switch in kernel and execute the ROM. Ok, doing
> that in userspace is more elegant, but that code is not a mess (though
> it's arch dependant).
And also some cards do rather deep magic or don't even have a real
video ROM but a BIOS hack that goes away. This got discussed - its fun
> Btw, how do we POST non-x86 (eg. ppc) video boards? I don't think that
> there's x86 code in their ROM...
Same way X does - x86emu
> > 7) Mode setting from normal user space - devices will have a standard
> > IOCTL accepting a mode string like fbdev currently uses.
>
> sysfs? I sent a patch a while ago but didn't get much feedback.
How do you atomically tie sysfs objects to fbdev and X permissions
models ?
> > 14) A new framebuffer memory manager is needed for mesa GL support. Ian
> > is working on it. The memory manager will be part of the support
> > library driver code.
>
> sisfb has a memory manager for fb/drm, it may be worth a closer look.
Its way too slow and doesn't deal with a lot of things it should, its a
problem even on DRI today. Ian has some design for a mostly user space
allocator which is critical as DRI can hit 100K allocs/second.
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
--
next prev parent reply other threads:[~2004-07-28 22:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-28 18:53 OLS and console rearchitecture Jon Smirl
2004-07-28 20:10 ` Alan Cox
2004-07-28 21:31 ` Kronos
2004-07-28 22:57 ` Alan Cox [this message]
2004-07-29 0:23 ` [Linux-fbdev-devel] " Jon Smirl
2004-07-29 0:44 ` Ian Romanick
2004-07-29 1:19 ` Jon Smirl
2004-07-29 8:34 ` Geert Uytterhoeven
2004-07-30 22:19 ` Kronos
2004-07-30 23:31 ` Jon Smirl
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=1091055478.31913.7.camel@localhost.localdomain \
--to=alan@lxorguk.ukuu.org.uk \
--cc=dri-devel@lists.sourceforge.net \
--cc=jonsmirl@yahoo.com \
--cc=kronos@people.it \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).