On 17 May 00 at 12:01, James Simmons wrote:
> > > All you are doing is redirecting output from one VT to another. It's the
> > > same as grep foo.txt > /dev/tty3 and getting output.
> > It was meant to show you that parameter 'con' passed to fb_get_var
> > and fb_set_var function HAS meaning and you cannot simply remove it.
> No it doesn't in that example. The text data output from that app is
> being redirected into another tty. This is handled in the tty layer. It
> has nothing to do with the con parameter.
Well, it looks that this example was too complicated for you :-(
So try this one instead:
switch to VT1 and do:
(sleep 5 ; fbset -depth 16) & chvt 5
It changes videomode of VT1 while you see VT5 (unless you have your
kernel, of course...) [if kernel dumps core during fbset, complain to
author of fbdev you are running; I believe that in 2.3.99-any all fbs
are correct]
Whole point is to show you that foreground VT does not equal to VT on
which fbset operates.
> > But I simple do not see
> > why you are still trying to remove possibility of setting different
> > vertical refresh, color depths or videomodes on different VT by stupid
> > idea that if not everyone can support it, so remove it completely...
> Just set the video mode with different columns and different number of
> rows or set a differnt font size on that VC. This will change the video
> resolution.
Where it finds upper/lower/left/rights margins and vslen/hslen? And pixclock?
And depth?
> Color depths:
> The console looks at a color as a color palette not a depth. At max
> their are 16 entries in the color palette.
You think this, probably.. I disagree, I see much better if I can set
videomode for fbtv before I start (with unified tool: fbset) instead of
having to duplicate this code (and user interface) in each application.
> Vertical refresh:
> With properly written driver it would find the best refresh rate for a
> mode. This would require knowing about the monitor and the video card. I
> plan to add this to fbdev.
Windows 95 did this. And afaik, users were VERY disappointed with this.
There are such things like interference, power consumption and so on -
it is nice that my monitor can do 640x480 in 160Hz, but I do not want
this - with 160Hz vertical refresh it consumes 200W, with 100Hz only
100Watts. Pretty big difference for me... On other side, for fbtv I
want exactly 50Hz or 100Hz, interlaced if possible to minimize tearing
effects...
> > Program? Just now I can run four instances of fbtv at once, one in left
> > up corner, one in right up, another in left down and right down... And it
> > works, hardware does not crash and everyone is happy. It is same like that
> > old Unix did not have mandatory locking -
> Multiple access to framebuffer is not the problem. In fact the PCI bus
> ensures serial access in a SMP environment. See below. UNIX does properly
> virtualize the hardware :)
And what's problem, then?
> > it is your problem if you did
> > not do proper locking (and if you have so stupid hardware that it can
> > die with inaprorpiate access, either remove rights to /dev/fb for non-root
> > or buy better hardware). But do not force open-once on us.
> Multiple access to the framebuffer is not the problem. The problem is
> if you run fbvt and you run libsvga on top of fbdev which changes the mode
> at the same time fbvt is running (think SMP). Their is a change of the
This is bug in application. How can I run libsvga on this VT if
I just use fbtv?
> hardware state by one app that effects all the other apps. You could use
> userland locks and save the hardware state. Just pray to god that all the
> apps behave right.
They will not. If I want to do this, it is my problem. But I can run
snes emulator on one VT and fbtv on another, and they'll correctly share
one framebuffer...
> With VTs its pointless to support anyways since only one VC is active
> at a time (single head). The other graphics apps will be put to sleep so
> they don't run in parallel. The ones that will run in parallel on a SMP
> machine will be on different pieces of video hardware.
They'll put to sleep itself. If they do not want, they do not have to.
> > you to some VT (and I want this behavior - I run X because of I must, not
> > because of I want and I want to be able to quicky switch between X and
> > anything else by simple ctrl-ralt-f12).
> Switching between X and console is okay but to support running a different
> X servers on every VC is just dumb when you can have a userland solution
> like virtual desktops. Not only that but its just expensive to do. If you
Why remove existing functionality?
> want a X server to support multihead then all it has to do is have one
> X server open all the avaliable /dev/fbX not multiple VTs. Once Vojtechs
> input system goes in and we have lost fo fbdev drivers then XFree86 will
> no longer need to touch any VTs to do anything.
And this is wrong! How can I switch to X then? Now it is pretty easy -
- hit ctrl-alt-f1..f12, ctrl-ralt-f1..f10, you are on tty 1..22. Hit
ctrl-ralt-f11, you'll get X on first head G400 and hit ctrl-ralt-f12 and
you'll get X on second G400 head (another config does not work, so do not
tell me to run X with two screens, it does not work).
> > > If Linus is okay with it I will send him some patches.
> > First check them... Do you remember your open once patch in 2.3.51-something
> > which broke almost all fb applications I know?
> The apps (Mesa, libsvga fbdev wrapper) I have did work fine. I didn't have
> the apps that toke advatange of the brokeness of the fbdev layer. Now I
It is not brokeness... It is just that you expect something else from
fbdev than what you get. Others are satisifed with what they get (well,
almost)... I think that more broken is that anybody with access to
/dev/fb* can mmap accelerator register and access them - it is like
giving /dev/mem access to him and this is what kills whole framebuffer
idea.
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.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:13 EST