Send plymouth mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freedesktop.org/mailman/listinfo/plymouth
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of plymouth digest..."
Today's Topics:
1. Re: [PATCH] drm: Don't override active mode. (Ray Strode)
2. Re: [PATCH] drm: Don't override active mode. (Forest Bond)
----------------------------------------------------------------------
Message: 1
Date: Sun, 13 Jun 2010 23:35:48 -0400
From: Ray Strode <[email protected]>
Subject: Re: [PATCH] drm: Don't override active mode.
To: Forest Bond <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hi,
On Sun, Jun 13, 2010 at 1:27 PM, Forest Bond <[email protected]> wrote:
> The drm renderer calls drmModeSetCrtc to tell the CRTC to use the
> allocated scan out buffer. ?This should not result in setting a
> new mode for the CRTC, but can do exactly that since plymouth saves
> the wrong mode when creating heads, and inadvertently overrides the
> initial mode set by the kernel.
>
> The root of the problem is the assumption that the first mode in the
> connector's mode list is the current active mode. ?This will be true
> if the active mode is set by automatic detection, as the kernel will
> have selected the first mode in the list as the initial mode, but it
> will not be true if the user has selected a different mode via the
> video= kernel boot parameter.
>
> To fix this, the saved mode is copied from the controller itself,
> unless that mode is for some reason not valid, in which case we fall
> back to the old behavior (which could result in a mode switch).
Ah, very clear description of the problem. Thanks for taking the time
to write such a detailed commit message.
Your patch seems basically fine, but I don't really like the idea of
calling drmModeFreeModeInfo on memory we allocate ourselves with
calloc.
I've done three commits here:
http://cgit.freedesktop.org/plymouth/commit/?id=abfda7550ac2fca6d816862e271126c2f44fa3cc
http://cgit.freedesktop.org/plymouth/commit/?id=b5b5f081bae003fd2d8065586249085f11d1c4a7
http://cgit.freedesktop.org/plymouth/commit/?id=9f25189bc8c6cb77cc37e3325e1089e23addf9a0
that restructure things, so we don't keep a duplicated copy of the
mode around in the head strucutre and attempts to fix yoru problems
I haven't given them any testing yet. Do they look okay to you?
--Ray
------------------------------
Message: 2
Date: Mon, 14 Jun 2010 07:35:42 -0400
From: Forest Bond <[email protected]>
Subject: Re: [PATCH] drm: Don't override active mode.
To: Ray Strode <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Ray,
On Sun, Jun 13, 2010 at 11:35:48PM -0400, Ray Strode wrote:
> On Sun, Jun 13, 2010 at 1:27 PM, Forest Bond <[email protected]>
> wrote:
> > The drm renderer calls drmModeSetCrtc to tell the CRTC to use the
> > allocated scan out buffer. ?This should not result in setting a
> > new mode for the CRTC, but can do exactly that since plymouth saves
> > the wrong mode when creating heads, and inadvertently overrides the
> > initial mode set by the kernel.
> >
> > The root of the problem is the assumption that the first mode in the
> > connector's mode list is the current active mode. ?This will be true
> > if the active mode is set by automatic detection, as the kernel will
> > have selected the first mode in the list as the initial mode, but it
> > will not be true if the user has selected a different mode via the
> > video= kernel boot parameter.
> >
> > To fix this, the saved mode is copied from the controller itself,
> > unless that mode is for some reason not valid, in which case we fall
> > back to the old behavior (which could result in a mode switch).
> Ah, very clear description of the problem. Thanks for taking the time
> to write such a detailed commit message.
After spending a few hours figuring out why my video= mode was not being
respected, it was a pleasure to get it all off my chest. ;)
> Your patch seems basically fine, but I don't really like the idea of
> calling drmModeFreeModeInfo on memory we allocate ourselves with
> calloc.
Thanks for taking a look. C is not my primary language, so you have a much
better sense of these things than I do. In thinking about it, I agree that
pairing malloc with drmModeFreeModeInfo doesn't quite feel right.
> I've done three commits here:
>
> http://cgit.freedesktop.org/plymouth/commit/?id=abfda7550ac2fca6d816862e271126c2f44fa3cc
> http://cgit.freedesktop.org/plymouth/commit/?id=b5b5f081bae003fd2d8065586249085f11d1c4a7
> http://cgit.freedesktop.org/plymouth/commit/?id=9f25189bc8c6cb77cc37e3325e1089e23addf9a0
>
> that restructure things, so we don't keep a duplicated copy of the
> mode around in the head strucutre and attempts to fix yoru problems
> I haven't given them any testing yet. Do they look okay to you?
These look fine to me. I can test them today or tomorrow and report back.
Thanks,
Forest
--
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/plymouth/attachments/20100614/a141d186/attachment-0001.pgp>
------------------------------
_______________________________________________
plymouth mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/plymouth
End of plymouth Digest, Vol 20, Issue 5
***************************************
