--- Michel D�nzer <[EMAIL PROTECTED]> wrote:
> As Alan pointed out on IRC, it won't. But providing the means to do it
I'm using code extracted from the reset function in Xfree. It seems to work for
Xfree, why shouldn't it work for me?
> cleanly is certainly good basically. The question is exactly where it
> belongs. I suggested to do this work on a branch for the time being, and
> got zero feedback. I don't know what that's supposed to mean; some
> people take silence as approval, but I don't.
I have six months worth of code that I can't check in because it all relies on a
sequence of patches. I have so many patches I am getting confused and losing
code. I'm doing this work for fun, I'm not getting paid, and lately it hasn't
been too much fun. If changes to DRM are going to be blocked please tell me now
and I will go work on another project.
It is obvious to me that the Longhorn desktop will be a generation ahead of
anything that Linux has to offer. A key MS decision was to build on top of
DirectX. The parallel on Linux is to bring up a standalone OpenGL/Mesa and then
implement xserver on top. If Linux is going to have a competitve offering then
we need to get standalone mesa working immediately in order to give the xserver
and higher layer people time to code. If Longhorn ships without a Linux response
it is going to greatly damage the progress Linux has been making on the desktop.
A major win would be to ship a hardware based compositing system before MS can.
In the long run FB and DRM need to be merged into a single driver. Cooperative
multitasking of multiple device drivers on the same piece of hardware is a bad
design and it has happened for historical reasons. DRM was designed from the
beginning to handle multiple clients, DMA security, framebuffer memory
management, etc. It is much easier to pull FB functions into DRM than the other
way around.
I have code that adds multihead mode setting with DDC support to DRM. It is
designed to allow independent users to use the two heads independently. Merged
FB mode is also supported. You could say add this code to FB but then you would
have to build a new FB API for it and teach FB about multiple clients and
framebuffer memory management. My first verision of this was based on the FB
implementation. But then I discovered that FB only implemented half of the
things needed and I rebuilt it using code from Xfree and DRM.
FB was built for a single user using a dumb 2D framebuffer. Leave it that way.
DRM is designed for a much more complex environment. There is nothing wrong with
loading a basic FB driver if that is all you want. If you want a complex desktop
environment load a DRM driver. Trying to make cooperating binaries is a lot of
hard work for no gain, it is much simpler to just pull some code from the FB
driver into the DRM one.
> > 2) vga_enable ioctl - this is used when reseting a card. Resetting a card
> > enables it VGA support so it is bad news if your reset a secondary card
> without
> > first disabling the primary VGA one. This ioctl disables all VGA devices.
> Then
> > you can reset the card. Then call the ioctl again to restore the initial VGA
> > device.
>
> What will happen if userland fails to restore it?
If you don't restore it the card you just reset becomes the VGA device. This
actually works. I'm running VGA console and the console moves to the other card.
Something is not quite right with font handing and I haven't tracked the problem
down. Logging out/in fixes it.
I had a a segfault handler that tried to set it back but because of the segfault
you might have two sets of VGA hardware enabled so I took the handler out.
=====
Jon Smirl
[EMAIL PROTECTED]
__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
