From: Jon Smirl <hidden> Date: 2005-02-21 19:48:08
XGL/mesa-solo is a project that has been going on for about a year and
a half now to get X running on top of OpenGL instead of the existing
2D XAA drivers. XGL allows a vastly improved user experience as
demonstrated at the recent X developer's conference. Removing the 2D
drivers from X means that things like mode setting need to come from
someplace else, like fbdev.
To make this project work XGL/mesa-solo needs support for these things
at the minimum:
1) resetting of secondary cards
2) mode setting on all heads, not just the primary one
3) hardware cursor control
4) control of mode setting/cursor etc by users, not just root
5) DRM and fbdev need to not conflict
We are try to get everything in the stack working together before OLS
this summer. I've posted code to implement some of these features and
I'm seeking solutions for making the rest work. Does this look like
something that can get finished in the next month or so? We also need
time to get all of the layers above fbdev using the new support.
--
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
From: James Simmons <hidden> Date: 2005-02-21 21:16:17
I have no problem helping you with this :-) In fact I'm very excited!!!!
Who is supporting your work? The problem is free time for me. Otherwise
I'm 100% behind you and want to work with you. If I could be sponsered for
this work by someone I would migrate to doing this for a living. I need to
eat too :-/
On Mon, 21 Feb 2005, Jon Smirl wrote:
XGL/mesa-solo is a project that has been going on for about a year and
a half now to get X running on top of OpenGL instead of the existing
2D XAA drivers. XGL allows a vastly improved user experience as
demonstrated at the recent X developer's conference. Removing the 2D
drivers from X means that things like mode setting need to come from
someplace else, like fbdev.
To make this project work XGL/mesa-solo needs support for these things
at the minimum:
1) resetting of secondary cards
2) mode setting on all heads, not just the primary one
3) hardware cursor control
4) control of mode setting/cursor etc by users, not just root
5) DRM and fbdev need to not conflict
We are try to get everything in the stack working together before OLS
this summer. I've posted code to implement some of these features and
I'm seeking solutions for making the rest work. Does this look like
something that can get finished in the next month or so? We also need
time to get all of the layers above fbdev using the new support.
-------------------------------------------------------
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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2005-02-22 07:23:15
On Mon, 2005-02-21 at 14:48 -0500, Jon Smirl wrote:
XGL/mesa-solo is a project that has been going on for about a year and
a half now to get X running on top of OpenGL instead of the existing
2D XAA drivers. XGL allows a vastly improved user experience as
demonstrated at the recent X developer's conference. Removing the 2D
drivers from X means that things like mode setting need to come from
someplace else, like fbdev.
To make this project work XGL/mesa-solo needs support for these things
at the minimum:
1) resetting of secondary cards
2) mode setting on all heads, not just the primary one
3) hardware cursor control
4) control of mode setting/cursor etc by users, not just root
5) DRM and fbdev need to not conflict
We are try to get everything in the stack working together before OLS
this summer. I've posted code to implement some of these features and
I'm seeking solutions for making the rest work. Does this look like
something that can get finished in the next month or so? We also need
time to get all of the layers above fbdev using the new support.
Finishing that in the next month or so is extremely optimist :)
I think we should do it the linux way, that is not take deadlines too
seriously, just do the stuff.
The first step is putting fbdev's and DRM driver together. I think it's
worth doing a stub right now rather than hacking radeonfb and the radeon
DRM together, because all other PCI card drivers at least will have the
same issues, and for various reasons, you may wnat to only use "half" of
it (that is not use the fbdev side or not use the DRM side), at least
for a while. (radeonfb doesn't always work 100% on all x86's)
The second step is to add video memory management & arbitration.
The third step is to add missing "features" like dual head etc.... and
the appropriate fbdev API changes to do it properly.
Ben.
-------------------------------------------------------
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
From: James Simmons <hidden> Date: 2005-02-22 17:31:58
Finishing that in the next month or so is extremely optimist :)
Try 5 to 10 years with us working in our spare time. It toke the input api
years to go in. The new fbdev system I worked on is the same way. I
started that code in 1999. 6 years and it still is not finished !!!!!!
Writing code in your spare time for free just doesn't work.
The first step is putting fbdev's and DRM driver together. I think it's
worth doing a stub right now rather than hacking radeonfb and the radeon
DRM together, because all other PCI card drivers at least will have the
same issues, and for various reasons, you may wnat to only use "half" of
it (that is not use the fbdev side or not use the DRM side), at least
for a while. (radeonfb doesn't always work 100% on all x86's)
The second step is to add video memory management & arbitration.
The third step is to add missing "features" like dual head etc.... and
the appropriate fbdev API changes to do it properly.
Forget it. Lets just work around the problems we have now. Attempting to
solve these kinds of problems will take so many years it is not worth it.
I personally realized it is not the worth the effort to do this. Just make
it work!!!
-------------------------------------------------------
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