When using vncv on a terminal with software cursor (vesa, rpi) the
mouse cursor leaves a trail. This seem to be caused by the fact that
vncv loads picture updates with loadimage(2) directly to screen.
Loading to an offscreen image followed by a draw(2) to screen removes
the artifact:
On Tue May 7 05:03:57 EDT 2013, yari...@gmail.com wrote:
When using vncv on a terminal with software cursor (vesa, rpi) the
mouse cursor leaves a trail. This seem to be caused by the fact that
vncv loads picture updates with loadimage(2) directly to screen.
Loading to an offscreen image
On Tue, May 7, 2013 at 4:10 PM, erik quanstrom quans...@quanstro.netwrote:
On Tue May 7 05:03:57 EDT 2013, yari...@gmail.com wrote:
When using vncv on a terminal with software cursor (vesa, rpi) the
mouse cursor leaves a trail. This seem to be caused by the fact that
vncv loads picture
This problem happens in 386 too (I mean the original
problem this patch is addressing or tries to address).
the problem is still in the kernel. hacking around it in
vnc won't fix the problem for other programs. hwdraw
should behave the same for either, so something in
the kernel should be
i am using the memdraw from p9p which fixes a number of
bad drawing cases. (no more blue pngs.) and i don't use
vnc, so it's hard for me to replicate.
I use 9atom on the pi daily and vncv often a d have never observed this
behavior.
I use 9atom on the pi daily and vncv often a d have never observed this
behavior.
does 9atom uses a higher HZ setting which could make swcursor be drawn sooner?
the issue, and this fact this fix works must mean that
devdraw(3)'s 'd' command usually doesn't cause (much)
cursor flicker, but the 'y' command does.
so either there is a timing or locking problem on the pi,
or swcursoravoid(r) is not called for the 'y' command.
Correct: swcursoravoid is
On Tue May 7 14:51:13 EDT 2013, yari...@gmail.com wrote:
the issue, and this fact this fix works must mean that
devdraw(3)'s 'd' command usually doesn't cause (much)
cursor flicker, but the 'y' command does.
so either there is a timing or locking problem on the pi,
or
i think the assertion that memload loads directly to the screen is not
correct.
at least to my walking through memload.
i read wrong. i think this may fix the issue in a systemic, but not
entirely satisfying way. it does seem rather optimistic that we can
just scribble on the screen.
