sony-vaio-z-series team mailing list archive

[Adam Hill <sidepipeuk@xxxxxxxxx>]

> > talking about the patch for random colours, or do you mean a 2.6.34
> kernel
> > with my additional changes? Essentially I'm not convinced that the 2.6.35
> > kernel is working at all currently on the 1600x900 panel and have no way
> of
> > testing it, so I don't know if patching the later kernel in this way
> would
> > be useful... though having said that I can't really try grub legacy on my
> > machine either without completely trashing it.
>
> Hmm, what does grub have to do with anything here?
>

In an ideal world, nothing... but clearly it does. That is just an
indication that the i915 driver is not right yet, it seems to be assuming
that the graphics hardware is in a particular state when that shouldn't be
the case - it shouldn't matter what boot loader you use but currently it
does. Apparently, the 2.6.34 kernel does not work at all if Grub2 is used (
though I'd be interested to know if anyone has tried with the grub 2 menu in
native resolution and gfxpayload=keep. ) The 2.6.35 kernel with my patches
seems better in that it will run with grub2 with specific settings and on
the HD panel, but it is still far from perfect. Switching to grub 1 allowed
me to load the i915 driver at kernel boot time, meaning no delay to start X,
and meaning a proper frame buffer for terminals where scrolling is no longer
painful. So currently grub has quite a bit to do with it.

I don't think the problem with intel is just colors.


I was referring to the 2.6.34 kernel here. Are you saying that with the
2.6.34 kernel without the patch, you get a black screen and/or freeze,
whilst with the same kernel version ( EXACTLY the same ) but after applying
the patch it works? This could indeed be the case, but that wasn't the
impression that I got from reading that page.


> I get a dead screen.  I
> could be wrong, but given that the patch is offered by someone with an
> @intel.com email address and that it was considered the correct fix for
> i915
> users after a lengthy launchpad discussion (which, regretfully, I lost the
> URL
> to), I think this patch deserves some attention.
>

Don't you think though that this being the case, those changes would already
be in later kernels? :) The reality of the situation is that the current
kernel DRM stuff is in a state of flux, and there have been major changes
between recent versions. I don't believe, for example, that the current
2.6.36-rc kernel works at all for us, no matter how we boot. It is also
quite possible that changes between 2.6.34 and 35 meant that 1600x900 no
longer works for us. I've looked at the patch on that page and it does
appear to be fixing an issue whereby the chip is not set to the correct
plane depth, which would mean strange colours on screen because the driver
is writing the wrong number of planes for each pixel. It also appears that,
whilst the 2.6.35 kernel is a little different in the way that it tests what
type of display you are using, the changes in that patch are ALREADY there.
Because of the differences between the major releases, it isn't immediately
obvious, but they are, or at least most of them are.

Just to make 100% sure, I have ported those changes again to 2.6.35 in the
same way that they were implemented in 34. In reality, this just results in
a duplication of a couple of status bits etc, but it was the only way for me
to be 100% sure that all of the changes were there. The result is in
http://www.voip-x.co.uk/files/adam/test/i915.ko which you should just be
able to copy over the
/lib/modules/2.6.35-rc6-vaioz/kernel/drivers/gpu/drm/i915/i915.ko module
from my original kernel ( and "update-initramrs -k -u 2.6.35-rc6-vaioz" just
in case. ) You can try it if you like, and if it DOES make a difference than
it may help to know what is really going on. I can't really see how it would
change things though.

Adam.