All of lore.kernel.org
 help / color / mirror / Atom feed
* [BUG] Strange interaction between X and /dev/fb0 + /dev/fb1
@ 2005-07-31  5:18 Knut Petersen
  2005-07-31  5:53 ` Antonino A. Daplas
  0 siblings, 1 reply; 2+ messages in thread
From: Knut Petersen @ 2005-07-31  5:18 UTC (permalink / raw)
  To: linux-fbdev-devel

Hi everybody,

  1: the system boots with video=vesafb:ypan
  2: cyblafb is loaded by the boot.local script
  3: con2vt /dev/fb1 /dev/tty1
  4: runlevel 3 (no X) is used

As cyblafb detects the video mode used by vesafb, everything works
fine. If I switch to tty1, the accelerated cyblafb driver is used, all other
ttys use the slow  vesafb code.
I can unload cyblafb after a con2ct /dev/fb0 /dev/tty1, load it again, 
switch
between ttys, everything without a problem.

Now I switch to runlevel 5.

  1: Switching from X to any tty, no matter if it is managed
     by vesafb or cyblafb,does work without problems.
  2: Switching from any tty to X works without a problem.
  3: Switching from X to any tty except tty1 (managed by cyblafb)
     and then between any ttys works without problems.

  4: Switching from X to tty1 and then to any other tty does _not_
     work. The cursor stops blinking, otherwise nothing changes
     on the monitor. Blindly entered commands produce no visible
     output, but they are executed.

  5: Switching to X and then back to the "dead" tty solves the problem.
     Output of the blindly run command is now visible, but scrolling
     took place only on the last line of the screen. Everything works
     fine as long as I do not repeat step 4 ;-)

2.6.12 and 2.6.13-rc4 behave identical.

As everything works without X, I do believe that there is no bug in the
framebuffer drivers involved. This is not a problem of programming some
hardware registers.

Loading two framebuffer drivers for one chip is a hack that is usefull
for devopement and debuging, it´s nothing a real user would do. We could 
silently
ignore this problem as there is an easy workaround. But the upper layers
see nothing but two different framebuffer drivers ... and this should be
handled correctly.

cu,
 Knut






-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [BUG] Strange interaction between X and /dev/fb0 + /dev/fb1
  2005-07-31  5:18 [BUG] Strange interaction between X and /dev/fb0 + /dev/fb1 Knut Petersen
@ 2005-07-31  5:53 ` Antonino A. Daplas
  0 siblings, 0 replies; 2+ messages in thread
From: Antonino A. Daplas @ 2005-07-31  5:53 UTC (permalink / raw)
  To: linux-fbdev-devel

Knut Petersen wrote:
> Hi everybody,
> 
>  1: the system boots with video=vesafb:ypan
>  2: cyblafb is loaded by the boot.local script
>  3: con2vt /dev/fb1 /dev/tty1
>  4: runlevel 3 (no X) is used
> 
> As cyblafb detects the video mode used by vesafb, everything works
> fine. If I switch to tty1, the accelerated cyblafb driver is used, all 
> other
> ttys use the slow  vesafb code.
> I can unload cyblafb after a con2ct /dev/fb0 /dev/tty1, load it again, 
> switch
> between ttys, everything without a problem.
> 
> Now I switch to runlevel 5.
> 
>  1: Switching from X to any tty, no matter if it is managed
>     by vesafb or cyblafb,does work without problems.

X restores, at least partially, the state of the card, then set_par
is called which fully restores the state of cyblafb.

>  2: Switching from any tty to X works without a problem.

X usually does a good job of restoring it's own state.

>  3: Switching from X to any tty except tty1 (managed by cyblafb)
>     and then between any ttys works without problems.

Vesa state is usually restored fully by X, so even if vesafb has
no set_par, vesafb comes back working.

> 
>  4: Switching from X to tty1 and then to any other tty does _not_
>     work. The cursor stops blinking, otherwise nothing changes
>     on the monitor. Blindly entered commands produce no visible
>     output, but they are executed.

I don't know why.  But try switching from tty1->X->tty1->!tty1 and
!tty1->X->tty1->!tty1. Do you still get the same behavior?
 
Tony


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-07-31  5:53 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-07-31  5:18 [BUG] Strange interaction between X and /dev/fb0 + /dev/fb1 Knut Petersen
2005-07-31  5:53 ` Antonino A. Daplas

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.