These are not isolated problems. Linux needs a properly designed
graphics subsystem. One way to achieve that is to design it all on
paper first so that we can try and locate the interactions between
modules. For example the current mode setting design is definitely
broken for multi-seat support, that's because you didn't take that
feature into account when writing the code.
No it isn't the code Jesse posted can handle multi-seat fine in the
areas that it makes sense as we've pointed out to you you cannot just
divide a GPU up into two head and not have the users interfere with
each other, reprogramming modes on multiple crtcs/outputs and setting
up memory bandwidth calculations requires the driver to do things that
will potentially disrupt the other user, in most cases setting a mode
on a head requires turning off all devices on the card first and
switching them back on in a certain order, this is usually due to
clocking interactions,
We can provide two fb interfaces for users wanting to do what you
want, we then need to fix the VT subsystem on top of that, however for
most of our users (like 95% at least) we want to support X as best we
can, and that is where the energy will be placed initially, reducing
the number of mode changes on startup along with suspend/resume for
users is a major goal of this work.
Putting a small module into the kernel first with a random API, then
try and build the next module is not a good development path. It is
better to design all of the modules on paper and then work backwards
to the API the first module needs. Even better would be to get the
whole subsystem working before including it in the kernel. Once these
exposed APIs go it, it is impossible to get them out. We need to try
and make sure that they are correct to begin with.
Fine, but nobody has succeded at this, because the effort of doing it
this way is not incrementally developed, we are not designing DX10, we
are improving Linux graphics one step at a time.
You need to take into account that you are proposing the replacement
of an existing subsystem, not the initial inclusion of a virgin
system. Putting your code in as is does make the X server happy, but
it is not solving all of the known problems with the existing graphics
subsystem. If you just want to make to X server happy it would be
better to extend the existing fbdev API and not try and replace the
subsystem.
The thing is we need integration with memory management, the memory
management is in the drm as it is complicated and the work is done, I
know you aren't even reading this sentence at this point.
Dave.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
