Daniel Vetter wrote:
> On Fri, Apr 19, 2013 at 10:41:50AM +0200, "David M?ller (ELSOFT AG)" wrote:
>> +/* GMBUS NAK handling seems to be unstable, hence let the
>> + * transmitter detection run in bit banging mode for now.
>> + */
>> +intel_gmbus_forc
Hello
As discussed in this thread
http://lists.freedesktop.org/archives/dri-devel/2013-April/037411.html
GMBUS based DVO transmitter detection seems to be unreliable which could
result in an unusable DVO port.
The attached patch fixes this by falling back to bit banging mode for
the time DVO tran
Daniel Vetter wrote:
> On Fri, Apr 19, 2013 at 10:41:50AM +0200, "David Müller (ELSOFT AG)" wrote:
>> +/* GMBUS NAK handling seems to be unstable, hence let the
>> + * transmitter detection run in
Hello
As discussed in this thread
http://lists.freedesktop.org/archives/dri-devel/2013-April/037411.html
GMBUS based DVO transmitter detection seems to be unreliable which could
result in an unusable DVO port.
The attached patch fixes this by falling back to bit banging mode for
the time DVO tran
Hello
I have a 855GME based system with a TFP410 DVO transmitter and running a
vanilla Linux-3.8 kernel.
With the activation of the hardware assisted GMBUS feature (somewhere
near kernel 3.5), the detection of the TFP410 DVO transmitter has become
flacky, which results in an unusable DVO port.
A
Hello
I have a 855GME based system with a TFP410 DVO transmitter and running a
vanilla Linux-3.8 kernel.
With the activation of the hardware assisted GMBUS feature (somewhere
near kernel 3.5), the detection of the TFP410 DVO transmitter has become
flacky, which results in an unusable DVO port.
A
Patrik Jakobsson wrote:
> I've sent in a patch for this:
> http://lists.freedesktop.org/archives/dri-devel/2013-February/034990.html
> it is slightly different to what I proposed earlier. Would be nice if you
> could
> give it a spin and report back.
Seems to be ok.
Tested-by:
Patrik Jakobsson wrote:
> I've sent in a patch for this:
> http://lists.freedesktop.org/archives/dri-devel/2013-February/034990.html
> it is slightly different to what I proposed earlier. Would be nice if you
> could
> give it a spin and report back.
Seems to be ok.
Tested-by:
__
Hi Patrik
Patrik Jakobsson wrote:
> The value of VCO_MIN comes from the Intel PRM for similar GPUs.
>
> Instead of changing VCO_MIN, could you try setting N_MIN=1, N_MAX=6 and
> M1_MAX=22? I'll test it on my own hardware tomorrow.
Thanks for your suggestion.
With "N_MIN=1, N_MAX=6 and M1_MAX=22
Hi Patrik
Patrik Jakobsson wrote:
> The value of VCO_MIN comes from the Intel PRM for similar GPUs.
>
> Instead of changing VCO_MIN, could you try setting N_MIN=1, N_MAX=6 and
> M1_MAX=22? I'll test it on my own hardware tomorrow.
Thanks for your suggestion.
With "N_MIN=1, N_MAX=6 and M1_MAX=22
Hello
I have a problem using a 1024x768 Eizo Monitor attached by DVI-D to a
system with GMA500 based graphics and running under Linux-3.7.
As soon as the GMA500 driver is taking over control, the refresh
rate raises to 64.5Hz and the monitor reports a "signal error".
For me i looks like the GMA5
Hello
I have a problem using a 1024x768 Eizo Monitor attached by DVI-D to a
system with GMA500 based graphics and running under Linux-3.7.
As soon as the GMA500 driver is taking over control, the refresh
rate raises to 64.5Hz and the monitor reports a "signal error".
For me i looks like the GMA5
Hello
I have a problem using a 1024x768 at 60Hz LVDS panel attached to a 855GME
based system running under Linux-2.6.39.
As long as the system is under VGA BIOS control, everything is fine
(panel refresh rate is 60.1Hz).
As soon as the i915 Linux driver is taking over control, the refresh
rate r
Hello
I have a problem using a 1024x768@60Hz LVDS panel attached to a 855GME
based system running under Linux-2.6.39.
As long as the system is under VGA BIOS control, everything is fine
(panel refresh rate is 60.1Hz).
As soon as the i915 Linux driver is taking over control, the refresh
rate rais
Hello
Any news?
http://lists.freedesktop.org/archives/dri-devel/2011-January/006875.html
Hello
Any news?
http://lists.freedesktop.org/archives/dri-devel/2011-January/006875.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Attached the corresponding patch for kernel 2.6.36.
Chris Wilson wrote:
> Nice patch, thanks. I've applied this to my -fixes queue.
So this means that this fix will be part of a future stable 2.6.37.x
kernel or will it be only part of the upcoming 2.6.38?
If it is the latter, shall i send the pat
Attached the corresponding patch for kernel 2.6.36.
Chris Wilson wrote:
> Nice patch, thanks. I've applied this to my -fixes queue.
So this means that this fix will be part of a future stable 2.6.37.x
kernel or will it be only part of the upcoming 2.6.38?
If it is the latter, shall i send the pat
Hello
Since Linux 2.6.36 the digital output on my system (855GME + DVI-I) is
not working any longer. The analog output is always activated regardless
of the type of monitor attached.
The culprit seems to be intel_crt_detect_ddc(), which returns true as
soon as an ACK from the EDID device is recei
Hello
Since Linux 2.6.36 the digital output on my system (855GME + DVI-I) is
not working any longer. The analog output is always activated regardless
of the type of monitor attached.
The culprit seems to be intel_crt_detect_ddc(), which returns true as
soon as an ACK from the EDID device is recei
20 matches
Mail list logo
