Linux Framebuffer Layer development
 help / color / mirror / Atom feed
From: Dzianis Kahanovich <mahatma@bspu.unibel.by>
To: linux-fbdev@vger.kernel.org
Subject: Re: [PATCH v5+] viafb: I2C/DDC LCD detection for VIA framebuffer
Date: Mon, 06 Dec 2010 13:53:14 +0000	[thread overview]
Message-ID: <4CFCEACA.3050600@bspu.unibel.by> (raw)
In-Reply-To: <4CF8DA25.4020204@bspu.unibel.by>

Florian Tobias Schandinat wrote:

> As Jon already mentioned, via-core.c is the wrong file for such things because
> via-core is meant for managing shared resources (between video capture and
> framebuffer at the moment) and EDID is only interesting for the framebuffer.
> Probably viafbdev.c would be the best choice.

I think about moving code, but another sense was - this code mix (eclectic)
calls from various places and called from here, then...

But OK.

>> +            if (!viafb_active_dev) {
>> +                viafb_DVI_ON >> +                    viaparinfo->tmds_setting_info->max_hres ?
>> +                    STATE_ON : STATE_OFF;
> 
> Doing such thing here looks wrong as this loop does not influence
> viaparinfo->tmds_setting_info

I have only card, incompatible with current tmds code - Chrome9 (0x3371). But
while I send patch, I think "legacy" DDC code must at least be compatible with
current code and not brake it. Really I have no tmds identifyed and this place
only disabling DVI if so (default enabled).

>> +                if (viafbinfo->monspecs.input & FB_DISP_DDI) {
>> +                    viafb_LCD_ON = STATE_ON;
> 
> It can happen that we enable LCD and DVI for the same device? Well nearly the
> only difference between LCD and DVI is backlight handling, so it should work,
> but it is ugly.

Then I must not enable LCD if DVI/tmds detected?
if ((viafbinfo->monspecs.input & FB_DISP_DDI) && !viafb_DVI_ON) {

- right? If there are only change I may make - do it if you will use this code.

Or just on start of function:
if (viaparinfo->tmds_setting_info->max_hres)
	return;

What is better?

> I like your EDID parsing code (the fact that you are using existing functions).
> But as we already have a poor open-coded EDID parser and as it would be very
> ugly to have two different methods of EDID parsing in the same driver you really
> should investigate whether your parser can't fully replace the one in dvi.c

Current parser just don't work with my card. But this - at least found good
resolution and whole LCD. Default I have dead DVI and CRT. And LCD resolution
not detected. I must change type to "17" (1024x600), default - "2" (1024x768).
This code is just working for me.

> And you should care about where the EDID information comes from:
> 0x21 => CRT, do not set lvds or tmds information
> 0x31 => DVP1:
[...]

OK. I will play with this.


-- 
WBR, Dzianis Kahanovich AKA Denis Kaganovich, http://mahatma.bspu.unibel.by/

  parent reply	other threads:[~2010-12-06 13:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-03 11:53 [PATCH v5+] viafb: I2C/DDC LCD detection for VIA framebuffer Dzianis Kahanovich
2010-12-04  0:13 ` Florian Tobias Schandinat
2010-12-06 13:53 ` Dzianis Kahanovich [this message]
  -- strict thread matches above, loose matches on Subject: below --
2010-12-03 11:32 [PATCH v5] " Dzianis Kahanovich

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=4CFCEACA.3050600@bspu.unibel.by \
    --to=mahatma@bspu.unibel.by \
    --cc=linux-fbdev@vger.kernel.org \
    /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