Re: Re: FBdev updates.

On Mon, 2003-03-10 at 05:29, Petr Vandrovec wrote:

Hi James,
  I tried to use fb_cursor and I have quite a lot problems with
it:
(1) it uses global variables for storing last cursor value -
    - but there is no global hardware, so after switching from
    one fbdev to another you can have cursor with wrong shape,
    wrong color and so on...
(2) callback from timer for cursor blinking may set almost any
    FB_CUR_* bits. But in this case fb_cursor callback may be
    called from interrupt context, while accelerator is busy
    and so on... Did I miss some synchronization? Best for me
    would be disabling blinking code in fbcon completely:
    in VGA mode cursor blinks automatically, and in graphics mode
    more lightweight only 'flash' callback is more appropriate
    for me. But then there is problem with

I've also noticed problems with 1 and 2, and I submitted a patch to
James that allocates resources on a per device basis instead of being
global and statically allocated.  This includes the cursor data
structures, cursor timer/vbl interrupt service, putcs buffer, and
optionally the softback buffer.  The last is probably not very important
for the present setup but may become useful later on (ie, multiple
active consoles).

As for synchronization, I was meaning to ask some pointers on that.  The
setup currently works like this:

                        (blink)
fbcon_cursor         fbcon_vbl_handler (interrupt or timer)   
     |                     |
     -----------------------
               |
           accel_cursor
               |
     -----------------------
     |                      |
  hardware              soft_cursor    accel_putcs    accel_putc
                            |              |               |
                            -------------- -----------------
                                           | 
                                   fb_get_buffer_offset
                                           |
                                     xxxfb_imageblit
                                           |
                                  -------------------
                                  |                  |
                              hardware           software


I was thinking of placing locks in accel_cursor and
fb_get_buffer_offset, but I'm not sure.
  

(3) cursor_undrawn... I have no idea how is this supposed to work

In the present cursor api, the driver just needs to draw/undraw the
cursor whether by software or hardware.  So the problem here is with
cursors that does it's own blinking, such as text modes.

    if fbdev provides hardware cursor... And HZ/50 delay after
    putcs makes orientation on screen very complicated, as there
    is no cursor while new characters are appearing on screen.

The delay is only for the blinking.  After drawing a character/stream of
characters, an explicit "draw cursor" command immediately follows (I
think) via fbcon_cursor.

Tony





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com