[BRLTTY] screen driver in brlapi

[Nicolas Pitre]

On Sat, 3 Nov 2018, Dave Mielke wrote:

> [quoted lines by Samuel Thibault on 2018/11/04 at 00:36 +0100]
> 
> >Ok, so we really have to read the whole screen before calling poll().
> 
> Not necessarily. It all depends on the paradigm. Let's say that brltty only
> ever cared about the part of the screen being shown on the display. Then that's
> the only bit that it'd need to read. If the display is moved then it could
> immediately read (without polling) the new area, and then use poll() to watch
> for a possible change.

poll() will always return if any change happened after the last read(). 
So it is possible for poll() to return even if the area you're 
interested in didn't change as there is no mechanism to specify the 
screen area you're interested in.

Now if you want the content from two separate regions of the screen at 
the same time then there is a possibility for a race. Say dhat you do:

	while (1) {
		seek(region_A);
		read(data_A);
		seek(region_b);
		read(data_B);
		poll();
	}

Then, by the time you get to read data_B, it is possible that data_A has 
changed. But because you call read() for data_B then poll() won't return 
despite not having read the new content for data_A again.

There are ways around that, like having a another thread that does 
poll() and only sets a flag when it returns, and having this flag 
cleared before reading data_A. If the flag is set after reading data_B 
then this means data_A has to be read again.  Or have separate threads 
for reading data_A and data_B. But this is a rather unlikely use case.

> Note that it's also best to poll vcsa, rather than vcsu, in order to catch
> cursor motion, dimension changes, etc.

You are right. In practice the kernel implementation makes no such 
distinction though, and poll() on either devices currently returns even 
if only the cursor has moved.


Nicolas