Re: New DRM model

> We could leave the screen in whatever mode it is in and start painting a console
> window on it. The driver would send drawing commands from all other sources into
> the bit bucket until this mode was exited (via a VT switch?). But then we have
> to figure out how to get a shell connected to it. This might work since we
> control the terminal emulator in the user space app and it can adjust the shell
> for the new random screen size.
> 
> This would be way better than what Linux has right now.

Ok, whatever we do, that mean we need to setup the proper infrastructure
for arbitration on access (typically a futex would be fine I suppose)
and then for notifying the client of "events" that happened right after
it gets the futex back I assume so it can react to these.

- A mode switch is one of them "you need to reset your state, all
pending commands flushed". The mode switch is triggered either by
the current application itself via the mode switching library, or
implicit due some hotplug detection of monitor (or pivot type monitors,
etc...)

- Ownership change. Probably split into a "console switch requested"
to which the current owner can reply by accepting or rejecting (like
the current mecanism), and a separate unconditional "you lost
ownership" to be sent typically when the kernel preempted the current
application with the debug console, or maybe via some other root
action (I miss the lack of ability of root to force a console switch
when my currently frontmost app grabbed it and is locked in some way).

Ben.