On Tue, 14 Mar 2000, Sven LUTHER wrote:
> On Tue, Mar 14, 2000 at 10:42:48AM -0500, James A Simmons wrote:
> >
> > On Tue, 14 Mar 2000, Sven LUTHER wrote:
> >
> > > On Mon, Mar 13, 2000 at 10:27:14AM -0500, jsimmons@ugradlib.acsu.buffalo.edu wrote:
> > > >
> > > > > There is O_NDELAY for audio devices, is not it?
> > > >
> > > > Try opening /dev/dsp. I don't think it will work. It shouldn't. I can see
> > > > lots of problems here.
> > > >
> > > > > BTW, it is really surprising
> > > > > that I cannot run 'fbset' from XF86_FBDev anymore :-(
> > > >
> > > > Doesn't X server have keys to changes modes. I know the regular XFree86
> > > > servers do. I have used keys for this. If X server fb doesn't do this then
> > > > its broken and it should function just like other X servers.
> > >
> > > changing mode is not the only reason why one wants to run fbset, ...
> >
> > Here is the main reasons why I have it so only one app can open /dev/fb at
> > a time. Its called SMP. Consider two apps running at the same time both
> > with /dev/fb opened. Problem:
> >
> > 1)
> > Both apps mmap the MMIO region. Both program the accel engine at the
> > same. Hey the card locks up.
> >
> > 2)
> > DRI and fbdev MMIO region. DRI is using accel engine. Some app running
> > from a xterm mmaps MMIO region then uses accel engine. The card locks up.
> >
> > 3)
> > Someone runs fbset while the X server is using accel engine via /dev/fb
> > or DRI. Card locks up. You should only change the mode when the accel
> > engine is idle.
> >
> >
> > Now do people agree with me that /dev/fb should only be opened once.
>
> Err, ...
>
> not, there is no reason i should not be able to change mode of Xfree-fbdev
> whit fbset, not sure it will work, but still that is xfree who is broken.
>
> But anyway, i don't agree with you, there is no reason that a lots of people
> can open /dev/fb in read only mode, sure if some guys want to write to it at
> the same time, it could cause problems, ...
Okay lets consider this. Now some video cards use different apertures for
their video memory. What I mean the framebuffer location is different for
8 bit (it's little endian) and 16 bit (big endian). Consider this.
You start your X server in 8 bit mode. Now it will have write access to
/dev/fb. Now you start some app which opens /dev/fb in read only mode and
gets the current fix info. fix->smem_start will point to the little endian
aperture right. Now your X server has properly ALT whatever function keys
that do change the video mode. Since the X server has write access it can
change the modes. So now you switch to 16 bit color mode which means
fix->smem_start has changed to the big aperture. Your other app is still
writing to where the little endian aperture was which is the wrong place.
See even read only mode can hurt you.
"Look its a text editor, no its a OS, no its Emacs"
James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:30 EST