Previously, C0::VT was implemented as a simple 'cursor down'. I.e. it
would behave as LF **until** it reached the bottom of the screen,
where instead of scrolling, it became a no-op.
See https://vt100.net/docs/vt102-ug/chapter5.html
The commit log says that was needed to get tiling in GNOME
working. However, I don't know *which* extension that was.
Force resizing in a configure event means we'll trash a perfectly
valid buffer on e.g. 'activated' state changes.
So, let's revert this for now, and if this breaks GNOME, let's try to
find another solution. If worse comes to worse, we can detect if we're
running under GNOME and do a force-resize then, but not on sane
compositors.
When applying scroll damage, we may have to re-render the
margins.
This is because when we SHM-scroll, we actually move the entire
surface, and thus we end up overwriting the top margin area with old
window content, and scroll in uninitialized memory in the bottom
margin.
But, we don't have to tell the compositor about this - the last frame
always contains correct margins; i.e. there's no change between the
last frame and current frame being rendered.
TODO: we _could_ micro-optimize and only damage the margins after a
surface resize. We do it slightly more often now, when dealing with
state changes in screen flash or scrollback searching. But I don't
think it's worth the effort.
Instead of locking the queue for each dirty row we append, and
signaling a condition variable, just keep the lock while going through
the visible rows.
Release the lock once done.
Since we take the lock *before* posting the 'start' semaphore, all
workers will be waiting for the lock to be released.
Then, one at a time they'll get the lock and pick a row to
render. The queue will never get empty - when all rows have been
rendered, each worker will pick a 'frame done' "job" from the queue,
and break the rendering loop.
Previously, we had to explicitly render the old cursor cell *before*
applying scrolling damage.
We then rendered all the dirty rows, *without* rendering the cursor -
even if the cursor cell was among the dirty rows.
Finally, when everything else was done, we explicitly rendered the
cursor cell.
This meant a lot of code, and unnecessary render_cell() calls, along
with unnecessary wl_surface_damage_buffer() calls.
This was a necessary in the early design of foot, but not anymore.
We can simply mark both the old cursor cell, and the current one, as
dirty and let the normal rendering framework render it. All we need to
do is pass the cursor column to render_row(), so that it can pass
has_cursor=true in the appropriate call to render_cell(). We pass -1
here for all rows, except the cursor's row, where we pass the actual
cursor column.
With this, there's no need to calculate whether the cursor is visible
or not; just mark it's cell as dirty, and if that row is visible, the
normal rendering will take care of it.
This also simplifies the state needed to be saved between two frames;
we only need a row pointer, and the cursor column index.
Part of https://codeberg.org/dnkl/foot/issues/35
When determining whether we should render a hollow block cursor,
i.e. to signal that we're unfocused, base the decision on the
terminals current keyboard focus, not visual focus.
* xcursor always set for all pointers
* xcursor sometimes not updated when it should be
* mouse grabbed state wasn't per seat, but global (i.e. "does at least
one seat enable mouse grabbing")
* selection enabled state wasn't per seat
That is, only call term_kbd_focus_in() if we're the *first* seat
focusing that terminal, and only call term_kbd_focus_out() if we're
the *last* seat that focused it.
Previously, we triggered a theme reload on output changes. This is
completely wrong. We may get a new output with a scale different from
the output the pointer is actually on.
Now, we store the current scale along with the theme. We then trigger
a call to reload the xcursor theme *every* time the pointer enters a
surface. When it does, we use the current scale factor of the terminal
that owns that surface.
If the terminal covers multiple outputs, with different scale factors,
we'll use the largest scale factor. This may not be 100% correct. But
to fix that, we'd need to track which regions of a surface are mapped
on which outputs. Too complicated I say.
