Re: OpenGL-based framebuffer concepts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



\
Where do you get 'tons'? There will probably be one for initial reset,
one for VESA based mode setting and a few more if there is device
specific code needed for a specific card.

Making console rely on a permanent daemon that is subject to getting
killed by the OOM mechanism is not a workable solution.

Jon stop trying to hammer everyone by repeating ad-nauseum statements
of little importance...

We can stop the OOM killer from killing the daemon if necessary.
running device drivers in userspace would sort of require this, we can
run the daemon from init and if it dies, have it respawn, it could put
persistent info in a shared memory segment provided by the DRM, just
because you can't think of any way around things, doesn't mean the
rest of us can't..

The same things apples to a lot of your other "issues" a /dev/ with
permissions is no more or less useful than a /tmp/.grphs_socket1 and 2
with permissions, you insistence that everything be controlled via the
kernel is another thing you've just failed to think about rather than
hammer on about it *must* do this.

I'm spending more time rebutting points you repeatedly make, please
accept that there are other solutions, and everytime you post a list
of things *YOU* believe *MUST* be done, remove the things we've shown
are possible to be done other ways...

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]
  Powered by Linux