Re: Merged repo for protocol headers? Why are they split?
On 28 November 2017 at 12:38, Daniel Martin wrote:
> On 27 November 2017 at 23:18, Peter Hutterer wrote:
>> On Mon, Nov 27, 2017 at 09:07:12PM +0100, Daniel Martin wrote:
>>> On 22 November 2017 at 07:45, Adam Jackson wrote:
>>> > On Wed, 2017-11-22 at 10:25 +1000, Peter Hutterer wrote:
>>> >> On Tue, Nov 21, 2017 at 03:28:20PM -0800, Dylan Baker wrote:
>>> >> > Your script splits each proto into a subdirectory, does it really make
>>> >> > sense to
>>> >> > do that, or should the final proto package have everything together in
>>> >> > the root?
>>> >>
>>> >> please no! if you merge all repos the history will be messy. With
>>> >> subdirectories
>>> >> at least you get a nice git log for each individual repo if you specify
>>> >> the
>>> >> directory name.
>>> >
>>> > Agreed, that'd be a useful property to preserve given how random the
>>> > repo and file names are.
>>>
>>> Just started to test an idea today, to get an even better history. The
>>> idea is basically (omitting details):
>>> 1. format-patch each commit into a patch, the filename includes the
>>> commit time (UTC)
>>>- patches of all repos become sorted and when applying them we get
>>> a nice history
>>> 2. hammer with sed on the patches
>>>- add a proto prefix to the subject
>>>- change initial position of files (i.e. move headers into
>>> include/X11/..., txts into doc/), no need to move files later
>>
>> if there are any commit messages that reference others ("Reverts commit
>> abcd123") you lose the reference because the sha is now different. so I'd
>> rather not do a re-commit of everything.
>>
>>> Surprisingly, this works pretty good for the first commits (reduced
>>> testing surface for the beginning). Last stop was at renames of files.
>>> But, I got another idea, which I can test tomorrow.
>>>
>>> The merge into subdirs looks straight forward and we can do that if I
>>> find a show-stopper. Deal?
>>
>> have you looked at subtree merges? Keeps the repo history for each merged
>> repository and the one from the top-level repository. And it forces you to
>> merge into a directory anyway, so that's a win right there.
>
> Oh? No, didn't knew that before. But, tested it:
> $ git remote add -f randrproto
> git://anongit.freedesktop.org/xorg/proto/randrproto
> $ git subtree add --prefix=randrproto/ randrproto master
>
> The history in the toplevel looks good. But, log -p shows the original
> paths in the commits. Okay, it doesn't rewrite history. I can deal
> with that.
> Though,
> $ git log (--graph) randrproto/randr.h
> just shows one commit from the subtree add.
>
One reasonably easy way to fold the repositories [while preserving all
the history] is via git filter-branch.
See xserver commit 35dc7c75150733dbcef8a18b6796f49a7c48ebee which
imports modesetting.
One could even script the process ;-)
Emil
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Merged repo for protocol headers? Why are they split?
On 27 November 2017 at 23:18, Peter Hutterer wrote:
> On Mon, Nov 27, 2017 at 09:07:12PM +0100, Daniel Martin wrote:
>> On 22 November 2017 at 07:45, Adam Jackson wrote:
>> > On Wed, 2017-11-22 at 10:25 +1000, Peter Hutterer wrote:
>> >> On Tue, Nov 21, 2017 at 03:28:20PM -0800, Dylan Baker wrote:
>> >> > Your script splits each proto into a subdirectory, does it really make
>> >> > sense to
>> >> > do that, or should the final proto package have everything together in
>> >> > the root?
>> >>
>> >> please no! if you merge all repos the history will be messy. With
>> >> subdirectories
>> >> at least you get a nice git log for each individual repo if you specify
>> >> the
>> >> directory name.
>> >
>> > Agreed, that'd be a useful property to preserve given how random the
>> > repo and file names are.
>>
>> Just started to test an idea today, to get an even better history. The
>> idea is basically (omitting details):
>> 1. format-patch each commit into a patch, the filename includes the
>> commit time (UTC)
>>- patches of all repos become sorted and when applying them we get
>> a nice history
>> 2. hammer with sed on the patches
>>- add a proto prefix to the subject
>>- change initial position of files (i.e. move headers into
>> include/X11/..., txts into doc/), no need to move files later
>
> if there are any commit messages that reference others ("Reverts commit
> abcd123") you lose the reference because the sha is now different. so I'd
> rather not do a re-commit of everything.
>
>> Surprisingly, this works pretty good for the first commits (reduced
>> testing surface for the beginning). Last stop was at renames of files.
>> But, I got another idea, which I can test tomorrow.
>>
>> The merge into subdirs looks straight forward and we can do that if I
>> find a show-stopper. Deal?
>
> have you looked at subtree merges? Keeps the repo history for each merged
> repository and the one from the top-level repository. And it forces you to
> merge into a directory anyway, so that's a win right there.
Oh? No, didn't knew that before. But, tested it:
$ git remote add -f randrproto
git://anongit.freedesktop.org/xorg/proto/randrproto
$ git subtree add --prefix=randrproto/ randrproto master
The history in the toplevel looks good. But, log -p shows the original
paths in the commits. Okay, it doesn't rewrite history. I can deal
with that.
Though,
$ git log (--graph) randrproto/randr.h
just shows one commit from the subtree add.
Am I doing it wrong?
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] glx: do not pick sRGB config for 32-bit RGBA visual
This fixes blending issues seen with kwin and gnome-shell when 32bit visual has sRGB capability set. Signed-off-by: Tapani Pälli Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103699 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103646 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103655 --- glx/glxscreens.c | 5 + 1 file changed, 5 insertions(+) diff --git a/glx/glxscreens.c b/glx/glxscreens.c index 73444152a..596d972e0 100644 --- a/glx/glxscreens.c +++ b/glx/glxscreens.c @@ -271,6 +271,11 @@ pickFBConfig(__GLXscreen * pGlxScreen, VisualPtr visual) /* If it's the 32-bit RGBA visual, demand a 32-bit fbconfig. */ if (visual->nplanes == 32 && config->rgbBits != 32) continue; +/* If it's the 32-bit RGBA visual, do not pick sRGB capable config. + * This can cause issues with compositors that are not sRGB aware. + */ +if (visual->nplanes == 32 && config->sRGBCapable == GL_TRUE) +continue; /* Can't use the same FBconfig for multiple X visuals. I think. */ if (config->visualID != 0) continue; -- 2.14.3 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
