From: Sergio Masci (sergio@xcprod.com)
Date: Mon 17 Dec 2001 - 20:05:42 IST
> Hi all --
>
> I'm trying to implement a simple flashing cursor, and I'm using screen
> mode G640x480x256. My problem is that if the cursor is printed with a Y
> (vertical) value of around 400 (say, 390 - 410), it gets intermittantly
> printed about 100 pixels to the upper left of where it should be.
>
> I've used both gl_write() and gl_fillbox() to print the cursor, and both
> have the same result.
>
> I've used both SVGAlib versions 1.4.x and 1.9.x and the problem is
> consistent.
>
> Any ideas? Has anyone experienced this sort of thing before?
Hi Jay,
Yes, I've seen a similar problem but under fbdev not svgalib. It happens
about once every 4-6 weeks (very rare) on my own stuff. It's as though your
write window has suddenly changed offset and your cursor (in my case the
mouse pointer) suddenly jumps away and then jumps back. I haven't tried to
track it down since I think it's out of my control. If it were a bug in my
code, you would not see it jump back since any function that might be
storing a local copy of the mouse position, updating the mouse position,
then setting it back would loose the local copy during mouse refresh and
would not be able to set it back i.e. it can't happen by accident since the
function has to return in order for the refresh to occur and once it has
returned it would need to be invoked in some pre-arranged special way to set
the mouse position back and that's only possible if the local copy hadn't
been lost by the function returning in the first place.
I think it's possibly one of two things:
1 ... a hardware bug that manifests itself as a write contention causing
writes to video registers sometimes being lost.
2 ... video register updates by my software being interrupted at a critical
point and the context of the update being changed between the set-up and
completion of the update (maybe a linux driver jumping in)
I have seen both types of problems on many other types of embedded systems
using combinations of multiple hardware registers to change a single
property e.g. the offset of the write bank within the SVGA memory map being
addressed as 2 bits in one register, 4 bits in another register, and some
mode bits in yet another register.
<digress> One system I worked on had to clock data out through a 2 bit
serial port into an 8 bits serial to parallel latch. Some of the bits in the
latch controlled current through a motor. Turn 2 on and current flowed in
one direction, turn a different two on and current flowed in the opersit
direction. Turn the wrong 2 on for any length of time and we start to smell
smoke (there were two wrong and right pairs). The only way to avoid the
smoke was to clock the data through the latch as quickly as possible and
hope that nothing stopped the process at the wrong time. Not exactly the
best use for a serial register I'd say
</digress>
> While I'm at it, maybe there's a better way to program a flashing cursor?
> Here's what I'm doing:
>
> 1) Early in the program, I set a timer that runs constantly throughout the
> program, even when I'm not using the cursor:
>
> signal(SIGVTALRM, catch_alarm);
> interval.it_interval.tv_sec = 0;
> interval.it_interval.tv_usec = 200000;
> interval.it_value.tv_sec = 0;
> interval.it_value.tv_usec = 200000;
> setitimer(ITIMER_VIRTUAL, &interval, NULL);
>
> According to Rus, leaving this running doesn't add much (any?) overhead.
>
> 2) Then, I have a global variable called "cursor" which can be either 0 or
> 1. Every time the timer goes off (5 times a second), I swap the value of
> cursor like so:
>
> void catch_alarm(int vtalrm)
> {
> cursor = (cursor == 1) ? 0 : 1;
> signal(SIGVTALRM, catch_alarm);
> }
>
> 3) If I need the flashing cursor then, I print it or erase it, depending
> on the value of "cursor".
>
> Is there a better way? My flashing cursor is fairly consistent, but
> sometimes it gets a little jittery when other processes are running. How
> does something like the bash shell cursor remain so fluid & constant?
>
>
> Thanks,
>
> -J
Have you tried putting your cursor flasher inside your alarm signal handler?
You would probably have to put some kind of guard around it to prevent it
updateing the screen while you are writing to the screen. Your screen lock
and unlock functions could also process missed blicks due to the screen
being locked when the blink occured.
BTW cursor = !cursor will also do what you want in place of cursor = (cursor
== 1) ? 0 : 1;
Regards
Sergio
------------------------------------------------------------------
Unsubscribe: To: listbot@svgalib.org
Body: unsubscribe linux-svgalib
This archive was generated by hypermail 2.1.4 : Wed 21 Jan 2004 - 22:10:24 IST