> Take your pick. An fbdev driver is nothing but a PCI driver that
> registers itself with the fbdev subsystem. Ditto a DRM driver, though
> the DRM and agpgart layering is royally screwed up ATM. Regardless, he
> who codes, wins.
There is significant architectural difference between the two schemes.
Is the base driver an absolute minimal driver that only serves as a
switch to route into the other drivers, or does the base driver
contain all the common code? I'm in the common code camp, DaveA is in
the minimal switch camp.
You should really stop saying what I want, and look at what I did, my
code is in those patches.
What you realise after working on this from both directions is that it
doesn't matter, you just need a lowlevel layer initially, that you can
bind functionality to, the first step is to allow the DRM and fb to
become aware and communicate with each other, once you have this, you
can then start shuffling code down into the lowlevel driver, without
breaking the functionality of the fbdev or DRM drivers.
I'm not having a switch between DRM and fbdev, its not one or the
other yet, you need to learn to take small steps, we just need to
formalise the relationship between the two so that they can deal with
each other being there in a better fashion than they do currently, and
also so we can better suspend/resume support etc.
Take memory management for example. I think the memory manager should
go into the base driver. The other strategy is for each driver to have
their own memory manager and then the base provides a way to select
which one is active. (Note that in all cases the complex part of
memory management is running in user space).
So far we have no memory management, and most of the plans I've seen
involved using a userspace system to do it, really we just want the
fbdev driver to be able to ask the DRM, so where the hell is the
frontbuffer, if the DRM is loaded and if it isn't just say I'm using
here.
> No "hopefully." X must be forced to use this driver, otherwise the
> system is unworkable.
I have had no success in making this happen.
And won't as long as you fight against it, we don't have to force X to
use it, we have to make it an option in X that distros turn on... we
have to let the X people keep doing their drivers the way they do
drivers... I'm still not convinced putting modesetting in kernel is at
all necessary, I think a simple MMIO parser to stop bad commands from
getting to the hardware is all we should need, modesetting normally
consists of a small number of operations.
Write register,
Read register,
Wait for something to happen (vblank, bit set in a register X times..)
I think we can write an interface via the DRM to do these, but these
are a for later thing, until the fbdev and DRM layers can communicate
it is not practical.
What is cooperation? Is it shared code in the base coordinating a
single state in the hardware, or is it save your state, I'm switching
to another driver, now I'm loading its state. We can't achieve
agreement on this.
It'll be hopefully shared-state handling I dislike the amount of
save/restore stuff we do now, however you have to remember for
suspend/resume we normally have to this anyways, so we end up having
all the save/restore code in the end.
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]
