From: Helge Deller <deller@gmx.de>
To: "Michel Dänzer" <michel@tungstengraphics.com>
Cc: linux-fbdev-devel@lists.sourceforge.net
Subject: Re: [PATCH] Do set var even if no fb_check_var() provided.
Date: Thu, 28 Aug 2008 23:43:57 +0200 [thread overview]
Message-ID: <48B71C1D.9040908@gmx.de> (raw)
In-Reply-To: <1219906414.4421.142.camel@thor.sulgenrain.local>
Michel Dänzer wrote:
> On Wed, 2008-08-27 at 23:49 +0200, Helge Deller wrote:
>> Geert Uytterhoeven wrote:
>>> On Wed, 27 Aug 2008, Takashi Yoshii wrote:
>>>> The behavior of FBIOSET_VSCREENINFO seems to be weired on FB which does
>>>> not
>>>> provides fbops->fb_check_var.
>>>> It doesn't set anything, but gets info->var instead, and returns no
>>>> error. It is just same as FBIOGET_VSCREENINFO does.
>>>>
>>>> IMHO, this should be one of the following candidates,
>>>> 1. set var without check.
>>>> 2. do nothing but return error (setting var is not supported).
>>>> or
>>>> 3. it's a bug (fb_check_var should always be provided).
>>>>
>>>> The patch at the bottom implements "1".
>>>>
>>>> Because I don't know API specification, nor the history of the code,
>>>> I would like people who knows well to discuss this.
>>> If the driver doesn't provide a fb_check_var(), it means it cannot
>>> change video mode. Hence this rules out #1.
>>>
>>> #2 is not acceptable, as it will break existing applications. It's also
>>> incorrect, as FBIOPUT_VSCREENINFO should succeed for supported modes.
>>> For unsupported modes, the mode should be rounded up to a supported mode,
>>> if possible. In the case of drivers that support one fixed mode only, this
>>> rounding up is relaxed to `rounding' to the sole supported mode.
>>>
>>> #3 is also wrong, as fb_check_var() has been deliberately made optional to
>>> simplify drivers that support one fixed mode only.
>>>
>>> Conclusion: nothing should be changed?
>> I'm not sure.
>> On parisc we just stumbled over exactly this problem where I think Takashi's
>> proposal "1." is probably the right solution.
>>
>> Please see my Xorg bugzilla entry:
>> https://bugs.freedesktop.org/show_bug.cgi?id=17153
>
> I believe (bugs.freedesktop.org is currently down) that's currently
> waiting for information from you. Namely, have you tried not specifying
> a Modes line in the xorg.conf SubSection "Display"? I think the Xorg
> fbdev driver should come up with the currently active mode in that case.
> If that doesn't work, please attach the corresponding Xorg.0.log to the
> bug report once bugzilla is back online.
Bugzilla (https://bugs.freedesktop.org/show_bug.cgi?id=17153 ) is
available again, and I've uploaded the xorg.conf file, as well as the
Xorg.0.log log file as requested.
Your idea about testing a few mode lines is normally a good idea.
On a PC I would do exactly this.
But on a pure framebuffer driver it's only necessary to know (and to
check), that it runs (for example) at 1024x768 pixels with 8bpp. The
monitor sync values shouldn't really matter and that is the problem in
this thread. X should not try to force a specific monitor frequency. It
won't suceed anyway. It's for some cards just not possible to switch
monitor frequencies or to know the current ones (and this is why those
drivers don't implement fb_check_var())...
Helge
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
next prev parent reply other threads:[~2008-08-28 21:44 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-27 5:09 [PATCH] Do set var even if no fb_check_var() provided Takashi Yoshii
2008-08-27 7:08 ` Geert Uytterhoeven
2008-08-27 21:49 ` Helge Deller
2008-08-28 6:53 ` Michel Dänzer
2008-08-28 21:43 ` Helge Deller [this message]
2008-08-28 22:08 ` Michel Dänzer
2008-08-28 22:16 ` Helge Deller
2008-08-28 22:18 ` Michel Dänzer
2008-08-28 22:23 ` Helge Deller
2008-08-28 22:30 ` Michel Dänzer
2008-08-28 22:35 ` Helge Deller
2008-08-28 22:47 ` Michel Dänzer
2008-08-28 7:45 ` Ville Syrjälä
2008-08-28 21:45 ` Helge Deller
2008-08-29 5:15 ` [PATCH] Add fb_check_var() for fixed mode device Takashi Yoshii
2008-08-29 7:07 ` Michel Dänzer
2008-08-29 7:48 ` Takashi Yoshii
2008-08-29 7:10 ` Geert Uytterhoeven
2008-09-04 1:56 ` Takashi Yoshii
2008-08-29 8:49 ` Michel Dänzer
2008-08-29 12:16 ` Geert Uytterhoeven
2008-08-29 13:51 ` Michel Dänzer
2008-08-29 14:14 ` Geert Uytterhoeven
2008-08-29 14:23 ` Michel Dänzer
2008-08-30 8:58 ` Helge Deller
2008-09-02 19:11 ` Helge Deller
2008-09-03 10:11 ` Michel Dänzer
2008-09-03 19:24 ` Helge Deller
2008-09-04 7:21 ` Takashi Yoshii
2008-08-29 17:38 ` Ville Syrjälä
2008-08-29 2:06 ` [PATCH] Do set var even if no fb_check_var() provided Takashi Yoshii
2008-08-29 7:03 ` Geert Uytterhoeven
2008-09-04 7:38 ` Takashi Yoshii
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=48B71C1D.9040908@gmx.de \
--to=deller@gmx.de \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=michel@tungstengraphics.com \
/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).