lkml.org 
[lkml]   [2003]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Linux-fbdev-devel] Re: FBdev updates.
On Mon, Mar 10, 2003 at 06:27:14AM +0800, Antonino Daplas wrote:
> On Mon, 2003-03-10 at 05:29, Petr Vandrovec wrote:
>
> 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.

Maybe just auditing code is enough: cursor_on should be zero while
we are inside accel_putc/putcs (or inside any other fb function), and
if cursor_on is zero, fbcon_vbl_handler should do nothing. So just making
sure that fbcon_vbl_handler is not running on other CPU while we set
cursor_on = 0 should be enough.

> > 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.

Why we schedule cursor painting at all then? While we are inside putcs,
we cannot paint cursor anyway (as we are busy with painting characters
at cursor position...) and fbcon_cursor(CM_DRAW) should restart timer interval
anyway (so you see cursor while you type characters, and not like Solaris
where cursor appears after you stop typing characters) (unfortunately when
I tried to verify how it behaves on secondary head of matrox (which does not
have hardware cursor), I made a typo and ...

Unable to handle kernel NULL pointer dereference at virtual address 00000196
printing eip:
c02f9258
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0060:[<c02f9258>] Tainted: PFS
EFLAGS: 00010202
EIP is at fb_open+0x28/0xf0
eax: c6ed2c30 ebx: 00000020 ecx: 00000001 edx: c04848e0
esi: 00000002 edi: 00000000 ebp: c6ed2c30 esp: c4bb3f18
ds: 007b es: 007b ss: 0068
Process con2fb (pid: 18180, threadinfo=c4bb2000 task=d874d940)
Stack: 00000006 c8a8aae4 c4bb2000 00000000 c8a8aae4 c01669ea c6ed2c30 c8a8aae4
dffe6830 c01435e3 c8a8aae4 c6ed2c30 dffe6830 00000000 c015af91 c6ed2c30
c8a8aae4 00000002 bffffe7a dcaa5000 c4bb2000 c015adb7 ca74978c dffe6830
Call Trace:
[<c01669ea>] chrdev_open+0xaa/0x110
[<c01435e3>] file_ra_state_init+0x23/0x40
[<c015af91>] dentry_open+0x1d1/0x1f0
[<c015adb7>] filp_open+0x67/0x70
[<c015b26b>] sys_open+0x5b/0x90
[<c0109983>] syscall_call+0x7/0xb

Code: 8b 86 94 01 00 00 b9 01 00 00 00 8b 10 85 d2 74 1c b8 00 e0

so I'll have to check it tomorrow on real dualhead system...)

Petr Vandrovec
vandrove@vc.cvut.cz



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:33    [W:0.077 / U:2.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site