Drivers backed by TTM memory manager don't support mapping the
kernel backed framebuffer console, so can't be used for doing
a smooth transition (unless you use /dev/fb). In single head
configurations, there isn't a big advantage to using libdrm
anyway, so we bail for TTM drivers.
It can be cumbersome to wait for multiple operations to finish before
pulling a trigger. In those cases, one option would be to have a
separate trigger for each operation, and then wait until every trigger
is pulled before pulling the main trigger.
This commit instead allows a trigger to get pulled more
than once before it actually fires. By calling ignore_next_pull
once for each suboperaton, and immediately pulling the trigger,
it won't fire until the last operation finishes.
The boot splash plugin now takes in a keyboard, text
displays, pixel displays, and the console.
I passes those along to the plugins, and listens for
key strokes to handle CTRL-L refresh and other keybindings.
So now it's assuming some of the role of ply-window.
Much of this code comes directly from ply-frame-buffer in libply,
but shoehorned to fit into the renderer plugin interface.
One improvement over the old code is it tracks VT changes, and
stops drawing when the wrong VT is active.
This is the graphical output portion of the window class. This
commit and the previous few commits lay the foundation needed
for dropping the window class and getting multi-head rendering support.
This is the text output portion of the window class. With this commit
and a subsequent commit to split out the graphical output portion,
we should be able to drop the window class.
As mentioned earlier, this will give us the flexibility we
need for multi-head rendering.
In order to support multiple rendering backends, and multi-head
monitor layouts, I'm moving the actually rendering to render
plugins.
Examples of plugins could be frame-buffer, drm fb, and x11
(for debugging).
The renderer class is responsible for loading the appropriate rendering
backend, and providing an interface for the rendering backend to
advertise multiple displays.
Right now we only check for a frame-buffer plugin, although, it isn't
implemented yet.
This is the terminal settings portion of the window class. With this
commit and subsequent commits to split out the higher level text output,
and graphical output portions, we should be able to drop window
in favor of the new display classes.
This serves a few purposes:
1) To watch for VT changes
2) To make VT changes
3) To put the console in KD_GRAPHICS mode
The latter is handled by the window class right now, but I want to
drop the window class.
This is the input portion of the window class. With this commit
and subsequent commits to split out the output portions, we should
be able to drop the window class.
This will give us the flexibility we need for multi-head rendering.
Right now a lot of pixel manipulation functions are in the frame buffer
code. This means it's hard to do these types of things without the
results showing up on the display.
Furthermore, we want to get away from one frame buffer anyway for
multihead support. I can imagine each display in a multihead
configuration with its own pixel buffer, so splash plugins can draw to
the independently.
This commit adds the start of a pixel buffer class, which just copies
and pastes most of pixel-twiddling frame buffer code. There are some
changes to deal with pixel buffers not always having a final alpha of
1.0, and some changes to provide a more flexible interface for masking
fill operations.
At some point it will probably gain copy-and-pastes of the resize an
rotate code from the image class as well, and provide a mechansim for
have subpixbufs where rowstride != width.
Sometimes it's necessary to deal with a disjoint
set of rectangles together.
One big example is when keeping track of which parts of
the screen have changed.
Another example would be for non-rectangular clip masks.
This commit adds a new region class to simplify the handling
of these types of cases.
Previously we were using ply_frame_buffer_area_t even
when not dealing with a frame buffer area.
This commit adds a new general purpose rectangle type
to replace ply_frame_buffer_area_t. It has some
convenience functions for operating on rectangles as well.
The event loop is used all through out the code
for many different things. In order to use it
in all those various bits of code, it's getting
passed around a lot. This adds a lot of complexity
to the code.
The event loop should probably be a standard
resource that all parts of the code have free access
to in the same vein as the logging apis.
This commit adds a new function
ply_event_loop_get_default () and makes main use it
and pass it along.
Subsequent commits may clean up all the places that
take an event loop to just use this instead.
It was a really lame small wrapper around creating pseudoterminals.
The wrapper didn't buy anything and the name ply-terminal would be
better used for managing tty settings, etc.
Before we were counting space that could only fit a partial bullet as room
for a whole bullet. Now we look and see if there is enough extra space for
at least half a bullet (since the code will draw half a bullet in the case
of more bullets than can fit)
The name "console" is sort of ambiguous. It could mean:
1) the keyboard and mouse together (also known as "seat")
2) the VT console
3) /dev/console
4) where /dev/console messages should go
In this case we mean 4, so we rename it to kernel_console_tty
for clarity.
