> On 21 November 2009 05:27, Dave Airlie <airl...@gmail.com> wrote:
>
> > At the moment the problem with fbset is what to do with it in the
> > dual head case. Currently we create an fb console that is lowest
> > common size of the two heads and set native modes on both,
>
> Does that mean that fbset is supposed to work (set resolution) on drmfb?
Yes it could work. No it doesn't work.
> >
> > Now if a user runs fbset, I'm not sure what the right answer is,
> > a) pick a head in advance via sysfs maybe and set it on that.
> > b) try and set the mode on both heads cloned (what to do if
> > there is no common mode is another issue).
> >
>
> I would say it's time to support multihead with fbset properly.
>
> That is people would need new fbset which sees both (all) heads, and
> fbset can then choose the head itself (and people can make it do
> something different when they don't like the default). It should also
> support setting up rotation on each head.
>
> For old fbset setting something visible is probably good enough.
>
> Schemes which would make a multihead setup look like a single screen
> get complicated quite easily. Perhaps an option to turn off some
> outputs so that the native resolution of one output is used (instead
> of clone) would work.
Before we go there you have to reflect on what the original reason was
to
have a framebuffer layer. The point to have a VT console terminal on
platforms that lacked hardware that supported native text mode hardware.
In other words had no vga text mode. A VT terminal is just a keyboard and
a display. In fact in the old days you had to write framebuffer console
drivers with things like con_putcs, con_write. Then the api was changed to
make driver writing simple. The struct fb_info represented your graphics
card.
Of course at that time we also had hardware that supported more
than one crtc which made things more complex. This was reflected in the
new api. Struct fb_info was moved in the direction to represent the
display. Remember the terminal only really cares about the display. Inside
struct fb_info we have a void *par that was a pointer to some structure
that represented the graphics card itself. So in the case of multi-head
systems you could have two struct fb_info and one shared *par. That way if
you wanted to changed the resolution on one screen the check_var function
could using the *par to test if the hardware could support both
resolutions at the same time.
Note also there is exist a sysfs that allows you to migrate your
second fbdev devices to a new terminal. Also problems exist in the upper
console layers that prohibit true multi-desktop systems.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
