On Thursday 08 June 2006 03:02 am, Helge Hafting wrote:
> 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.
Okay. I'll stick this on my list. Shouldn't be too hard to get to, provided I
can finish up my work on drmcon. (Tony, I'm still waiting on that unloadable
fbcon/fbdev bit and the userspace fbdev driver you mentioned)
> >> > 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
Actually, if drmcon works out right all that would be needed is a program that
can use FreeType to load the font into the driver.
DRH
-
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]
