From: Jon Smirl <jonsmirl@gmail.com>
To: linux-fbdev-devel@lists.sourceforge.net
Subject: Re: [patch] radeonfb: FB_WAITFORVSYNC implementation
Date: Sat, 12 Mar 2005 12:56:33 -0500 [thread overview]
Message-ID: <9e47339105031209566791e3b9@mail.gmail.com> (raw)
In-Reply-To: <1110648119.5997.100.camel@atlantis.netenviron.com>
On Sat, 12 Mar 2005 17:21:58 +0000, Torgeir Veimo <torgeir@pobox.com> wrote:
> On Sat, 2005-03-12 at 17:03 +0000, Torgeir Veimo wrote:
> > On Sat, 2005-03-12 at 10:33 -0500, Jon Smirl wrote:
> > > You can't do this without coordination from X and DRM.
> >
> > > Because of these issues WAITFORVSYNC in radeondb has to wait for
> > > merged DRM/fbdev to be implemented.
> >
> > It's a bit hard to track the merge-dri-and-db work,
>
> ^^ merge-dri-and-fb
Merging DRM and fbdev is happening in bits and pieces in both DRM and
fbdev. I've already tried once at building it as a separate project
and the political hassles of getting it merged made me stop. The new
approach is to add the various bits to both drivers until they will
merge with each other. A big piece of getting fbdev ready for DRM was
getting the extended sysfs and module support that just went in.
BenH is working on a new version of radeonfb with support for both
heads. I've stopped working on radeonfb until this lands since it
changes 90% of the code.
Once the foundation is in place I'll modify DRM to attach to fbdev
instead of loading as a standalone driver. At that point we can work
on shared interrupt and buffer management code.
There are still some major unsettled issues:
1) where is the list of valid modes computed? in-kernel or user space.
Technically either will work but each has plus and minuses. Right now
radeonfb can do both.
1a) #1 is computing the mode list, not setting the mode. The mode is
always set in the kernel.
2) multiheads implies buffer management, this needs to be coordinated with DRM
3) fbdev needs to implement hardware cursors
4) The fb_info struct doesn't work too well for multiple heads. It
really should be split up into fb_device/fb_head.
5) driver initiated secondary card reset needs to be implement via a
user space helper.
6) fbcon is tied way too closely to fb_info. There should be an
interface instead of just letting it muck around in fbdev data
structures.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
next prev parent reply other threads:[~2005-03-12 17:56 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-12 14:06 [patch] radeonfb: FB_WAITFORVSYNC implementation Torgeir Veimo
2005-03-12 15:13 ` Ville Syrjälä
2005-03-12 16:59 ` Torgeir Veimo
2005-03-12 17:10 ` Michel Dänzer
2005-03-12 17:12 ` Torgeir Veimo
2005-03-12 19:20 ` Michel Dänzer
2005-03-12 19:35 ` Jon Smirl
2005-03-12 23:33 ` Benjamin Herrenschmidt
2005-03-12 17:33 ` Ville Syrjälä
2005-03-16 1:28 ` Torgeir Veimo
2005-03-16 1:59 ` Ville Syrjälä
2005-03-16 6:19 ` Michel Dänzer
2005-03-12 15:33 ` Jon Smirl
2005-03-12 15:51 ` Ville Syrjälä
2005-03-12 16:00 ` Jon Smirl
2005-03-12 16:10 ` Ville Syrjälä
2005-03-12 16:21 ` Jon Smirl
2005-03-12 23:23 ` Benjamin Herrenschmidt
2005-03-12 17:03 ` Torgeir Veimo
2005-03-12 17:21 ` Torgeir Veimo
2005-03-12 17:56 ` Jon Smirl [this message]
2005-03-12 23:21 ` Benjamin Herrenschmidt
2005-03-12 23:14 ` Benjamin Herrenschmidt
2005-03-13 3:15 ` Torgeir Veimo
2005-03-12 23:30 ` Benjamin Herrenschmidt
2005-03-16 1:28 ` Torgeir Veimo
[not found] <20050313012923.60373.qmail@web14926.mail.yahoo.com>
2005-03-13 1:37 ` Benjamin Herrenschmidt
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=9e47339105031209566791e3b9@mail.gmail.com \
--to=jonsmirl@gmail.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 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).