Jon Smirl wrote:
On 6/1/06, Dave Airlie <[email protected]> wrote:
> Without specifying a design here are a few requirements I would have:
>
> 1) The kernel subsystem should be agnostic of the display server. The
> solution should not be X specific. Any display system should be able
> to use it, SDL, Y Windows, Fresco, etc...
of course, but that doesn't mean it can't re-use X's code, they are
the best drivers we have. you forget everytime that the kernel fbdev
drivers aren't even close, I mean not by a long long way apart from
maybe radeon.
This requirement means that stuff like mode setting has to be broken
out into an independent library. For example it would not be ok to say
that Fresco has to install X to get mode setting. No comment was made
on where the code comes from, you are reading in something that isn't
in the requirement.. I am aware that X has the best mode setting code
and it would be foolish to ignore it.
Both you and I both know what a pain it is to extract this type of
code from X. Let's not repeat X's problems in this area. Let's make
the new library standalone and easy to work with in any environment.
No all encompassing typedef systems this time.
> 2) State inside the hardware is maintained by a single driver. No
> hooks for state swapping (ie, save your state, now I'll load mine,
> ...).
We still have to do state swapping, we just don't expose it,
suspend/resume places state swapping as a requirement.
I don't consider suspend/resume state swapping, it is state save and
restore. The same state is loaded back in.
Other than suspend/resume why would the driver need to do state swapping?
> 9) there needs to be a way to control the mode on each head, merged fb
> should also work. Monitor hotplug should work. Video card hot plug
> should work. These should all work for console and the display
> servers.
Of course, have you got drivers for these written? this is mostly in
the realms of the driver developer, the modesetting API is going to
have to deal with all these concepts.
This needs to be considered in the design stage. For example, if both
heads are mapped through a single device node they can't be
independently controlled by two different user IDs. We need to make
sure we leave the path open to building this.
Yes. Having two nodes should fix this one though. The two nodes
can of course be managed by the same driver, so as to deal with
issues when there are some shared resources like memory
and a single graphichs accelerator.
> 10) Console support for complex scripts should get consideration.
not really necessary.. nor should it be... fbset works, something like
it would be good enough..
I meant support for Korean, Chinese, etc. You can't draw some of the
complex scripts without using something like Pango. Do we want to
build a system where people can use console in their native language?
That is very nice to have. Of course, it is acceptable to say that
those who want a Korean/Chinese console are the ones who have to
program that part themselves too, but the console design should not
prevent this.
Helge Hafting
-
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]
