From: Jon Smirl <jonsmirl@gmail.com>
To: linux-fbdev-devel@lists.sourceforge.net
Subject: Re: sysfs support for framebuffer
Date: Mon, 21 Feb 2005 17:15:35 -0500 [thread overview]
Message-ID: <9e473391050221141525aea1ef@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.56.0502212117240.16017@pentafluge.infradead.org>
On Mon, 21 Feb 2005 21:36:38 +0000 (GMT), James Simmons
<jsimmons@www.infradead.org> wrote:
> Now there is a problem to the above. If we have more than one graphics
> card it will get messy. I would guess the X server wants to know what
> things belong to what device. For example the matrox card supports dual
> heads. What if we have 3 graphics cards. Which two fbX devices belong to the
> matrox card. You could scan all the directories and organize a list for
> what belongs to what but that would be messy. Plus what if we plug
> a monitor in. We have to know which things (fb, mmio) effect its output.
I don't see a problem with the current structure. A two headed card
would show up as fb0 and fb1. The modelist for fb0 and fb1 would both
contain an entry for merged-fb. If you own both devices, then setting
the merged-fb mode will simply disable the other device. Same for
mirroring. If you don't own both devices the shared modes won't be in
the list. Device fb2 would list none of the shared modes. If you
really need to know then both fb0 and fb1 are linked to the same
device node in sysfs.
You are also pointing out a weakness in the fb_info structure. fb_info
is not designed for multiple heads. I can copy it like the matrox case
but this causes a lot of fields that should not be shared to be
copied. A much better design would be to break the structure up into
fb_device and fb_head. Then have an fb_head struct for each head. This
would also reduce the surface area of what fbcon is seeing since it
only needs to see the fb_head structure.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
prev parent reply other threads:[~2005-02-21 22:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-18 22:35 sysfs support for framebuffer Jon Smirl
2005-02-21 18:50 ` James Simmons
2005-02-21 19:33 ` Jon Smirl
2005-02-21 21:36 ` James Simmons
2005-02-21 22:15 ` Jon Smirl [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9e473391050221141525aea1ef@mail.gmail.com \
--to=jonsmirl@gmail.com \
--cc=linux-fbdev-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).