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