Hey all, Apologies for the direct ping. I've harvested your emails from drm_hwc git logs, and didn't want to leave anyone out. The good news is that your email address will forever be remembered in the annals of drm_hwcomposer!
Anyways, back to the point.
Now that we have our shiny freedesktop gitlab instance [1], we should really start using it to its fullest extent. This means 2 things:
1- When you send patches, please consider using gitlab merge requests instead of git send-email. This is not mandatory, but dri-devel is so busy, I want to make sure things aren't lost. Further, there might be some who are not interested in reading dri-devel *gasp*, but who are interested in drm_hwc. 2- If you're interested in being notified of merge requests (since dri-devel can not be cc'd), please consider clicking "Watch" on the project and choose your desired notification level.
If you're still reading, I'll point out a couple other things: - There is a bug tracker on the gitlab instance, feel free to add bugs/features/etc to it. - I've added a TODO list to the wiki, but in typing this, realized it's probably better to file bugs for each item. So please ignore the TODO wiki entry.
Thanks for reading,
Sean
[1]- https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer
On Thu, May 3, 2018 at 5:04 PM, Sean Paul seanpaul@chromium.org wrote:
Hey all, Apologies for the direct ping. I've harvested your emails from drm_hwc git logs, and didn't want to leave anyone out. The good news is that your email address will forever be remembered in the annals of drm_hwcomposer!
Anyways, back to the point.
Now that we have our shiny freedesktop gitlab instance [1], we should really start using it to its fullest extent. This means 2 things:
1- When you send patches, please consider using gitlab merge requests instead of git send-email. This is not mandatory, but dri-devel is so busy, I want to make sure things aren't lost. Further, there might be some who are not interested in reading dri-devel *gasp*, but who are interested in drm_hwc. 2- If you're interested in being notified of merge requests (since dri-devel can not be cc'd), please consider clicking "Watch" on the project and choose your desired notification level.
If you're still reading, I'll point out a couple other things:
- There is a bug tracker on the gitlab instance, feel free to add bugs/features/etc to it.
- I've added a TODO list to the wiki, but in typing this, realized it's probably better to file bugs for each item. So please ignore the TODO wiki entry.
Any plans to wire up autobuilder or maybe even functional CI to the gitlab instance? That's where stuff gets really cool (and I think a lot of people will see the value of abandoning dri-devel much more, beyond the better S/N ratio).
Cheers, Daniel
Thanks for reading,
Sean
[1]- https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer
-- Sean Paul, Software Engineer, Google / Chromium OS _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, May 03, 2018 at 08:30:18PM +0200, Daniel Vetter wrote:
On Thu, May 3, 2018 at 5:04 PM, Sean Paul seanpaul@chromium.org wrote:
Hey all, Apologies for the direct ping. I've harvested your emails from drm_hwc git logs, and didn't want to leave anyone out. The good news is that your email address will forever be remembered in the annals of drm_hwcomposer!
Anyways, back to the point.
Now that we have our shiny freedesktop gitlab instance [1], we should really start using it to its fullest extent. This means 2 things:
1- When you send patches, please consider using gitlab merge requests instead of git send-email. This is not mandatory, but dri-devel is so busy, I want to make sure things aren't lost. Further, there might be some who are not interested in reading dri-devel *gasp*, but who are interested in drm_hwc. 2- If you're interested in being notified of merge requests (since dri-devel can not be cc'd), please consider clicking "Watch" on the project and choose your desired notification level.
If you're still reading, I'll point out a couple other things:
- There is a bug tracker on the gitlab instance, feel free to add bugs/features/etc to it.
- I've added a TODO list to the wiki, but in typing this, realized it's probably better to file bugs for each item. So please ignore the TODO wiki entry.
Any plans to wire up autobuilder or maybe even functional CI to the gitlab instance? That's where stuff gets really cool (and I think a lot of people will see the value of abandoning dri-devel much more, beyond the better S/N ratio).
Not as far as I know. A fun afternoon project might be to hook up clang-format verification as a merge request hook. Aside from that, I think proper (or even improper/simple) CI would require more effort than we have resources.
Sean
Cheers, Daniel
Thanks for reading,
Sean
[1]- https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer
-- Sean Paul, Software Engineer, Google / Chromium OS _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Thu, May 03, 2018 at 03:12:55PM -0400, Sean Paul wrote:
On Thu, May 03, 2018 at 08:30:18PM +0200, Daniel Vetter wrote:
On Thu, May 3, 2018 at 5:04 PM, Sean Paul seanpaul@chromium.org wrote:
Hey all, Apologies for the direct ping. I've harvested your emails from drm_hwc git logs, and didn't want to leave anyone out. The good news is that your email address will forever be remembered in the annals of drm_hwcomposer!
Anyways, back to the point.
Now that we have our shiny freedesktop gitlab instance [1], we should really start using it to its fullest extent. This means 2 things:
1- When you send patches, please consider using gitlab merge requests instead of git send-email. This is not mandatory, but dri-devel is so busy, I want to make sure things aren't lost. Further, there might be some who are not interested in reading dri-devel *gasp*, but who are interested in drm_hwc. 2- If you're interested in being notified of merge requests (since dri-devel can not be cc'd), please consider clicking "Watch" on the project and choose your desired notification level.
If you're still reading, I'll point out a couple other things:
- There is a bug tracker on the gitlab instance, feel free to add bugs/features/etc to it.
- I've added a TODO list to the wiki, but in typing this, realized it's probably better to file bugs for each item. So please ignore the TODO wiki entry.
Any plans to wire up autobuilder or maybe even functional CI to the gitlab instance? That's where stuff gets really cool (and I think a lot of people will see the value of abandoning dri-devel much more, beyond the better S/N ratio).
Not as far as I know. A fun afternoon project might be to hook up clang-format verification as a merge request hook. Aside from that, I think proper (or even improper/simple) CI would require more effort than we have resources.
A couple additional thoughts,
We have seen a good uptick in drm_hwc activity in the last month or so, so maybe there is someone with time to do this.
The other (imo significant) benefit gitlab has in addition to S/N is that it's not an email-based workflow. I'm particularly looking forward to reviewing patches side-by-side instead of in a mutt window :-).
Sean
Sean
Cheers, Daniel
Thanks for reading,
Sean
[1]- https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer
-- Sean Paul, Software Engineer, Google / Chromium OS _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
-- Sean Paul, Software Engineer, Google / Chromium OS
Hi,
On 3 May 2018 at 20:12, Sean Paul seanpaul@chromium.org wrote:
On Thu, May 03, 2018 at 08:30:18PM +0200, Daniel Vetter wrote:
On Thu, May 3, 2018 at 5:04 PM, Sean Paul seanpaul@chromium.org wrote:
If you're still reading, I'll point out a couple other things:
- There is a bug tracker on the gitlab instance, feel free to add bugs/features/etc to it.
- I've added a TODO list to the wiki, but in typing this, realized it's probably better to file bugs for each item. So please ignore the TODO wiki entry.
Any plans to wire up autobuilder or maybe even functional CI to the gitlab instance? That's where stuff gets really cool (and I think a lot of people will see the value of abandoning dri-devel much more, beyond the better S/N ratio).
Not as far as I know. A fun afternoon project might be to hook up clang-format verification as a merge request hook. Aside from that, I think proper (or even improper/simple) CI would require more effort than we have resources.
That should be pretty easy as a .gitlab-ci.yml. I'm working on getting support for qemu into the existing runner that we have, so it would be entirely possible to run a drm-hwc on a 'real' kernel, if you have something you can test under qemu.
For on-hardware testing (e.g. run it on freedreno + vc4 + ...), that's a whole other topic that we don't currently cover.
Cheers, Daniel
Heya,
On 2018-05-04 12:51, Daniel Stone wrote:
Hi,
On 3 May 2018 at 20:12, Sean Paul seanpaul@chromium.org wrote:
On Thu, May 03, 2018 at 08:30:18PM +0200, Daniel Vetter wrote:
On Thu, May 3, 2018 at 5:04 PM, Sean Paul seanpaul@chromium.org wrote:
If you're still reading, I'll point out a couple other things:
- There is a bug tracker on the gitlab instance, feel free to add bugs/features/etc to it.
- I've added a TODO list to the wiki, but in typing this, realized it's probably better to file bugs for each item. So please ignore the TODO wiki entry.
Any plans to wire up autobuilder or maybe even functional CI to the gitlab instance? That's where stuff gets really cool (and I think a lot of people will see the value of abandoning dri-devel much more, beyond the better S/N ratio).
Not as far as I know. A fun afternoon project might be to hook up clang-format verification as a merge request hook. Aside from that, I think proper (or even improper/simple) CI would require more effort than we have resources.
That should be pretty easy as a .gitlab-ci.yml. I'm working on getting support for qemu into the existing runner that we have, so it would be entirely possible to run a drm-hwc on a 'real' kernel, if you have something you can test under qemu.
I'm currently working on getting something like this up and running for normal feature development on my local machine.
That being said AOSP is a fast moving target. So we would have to pin the AOSP version and maybe bump it every year or so. I guess that goes for the kernel,mesa & libdrm as well.
Rob.
For on-hardware testing (e.g. run it on freedreno + vc4 + ...), that's a whole other topic that we don't currently cover.
Cheers, Daniel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi all,
I just wanted to share that I'm conducting "newbie" tests on oreo-x86 with drm_hwcomposer, gbm_gralloc and libdrm with latest gralloc_handle.h
and the results are good on nouveau, provided that some changes in drmresources are applied to avoid throwing errors for non connected connectors,
i965 completes bootanimation, but surfaceflinger is killed when trying to draw status bar and menu bar (annoying but true)
amdgpu (bonaire which supports atomic drm) is affected by problems in setting the correct mode on display (only txt cursor is shown) and there are SIGSEGV MAPERR at libskia trying to draw pixels.
There are also errors logged by drm_hwcomposer code, which I'm not much able to interpret/analyze correctly.
I would like to open issues on drm_hwcomposer with the details and logs when I encounter them, may I use gitlab or bugzilla for these drm_hwcomposer specific issues?
Thanks for instructions
Another question is for Intel and Chromeos developers: are you planning to update your minigbm projects to the new common gralloc_handle.h handle structure in latest libdrm?
I'm asking because freedesktop drm_hwcomposer (hwctwo) moved to new libdrm gralloc_handle.h handle and it would make sense for minigbm to evolve accordingly,
and I'd like to try them in oreo-x86 as a like-for-like replacement option for gbm_gralloc
Thank for any info
Mauro Rossi
Il 04 mag 2018 14:48, "Robert Foss" robert.foss@collabora.com ha scritto:
Heya,
On 2018-05-04 12:51, Daniel Stone wrote:
Hi,
On 3 May 2018 at 20:12, Sean Paul seanpaul@chromium.org wrote:
On Thu, May 03, 2018 at 08:30:18PM +0200, Daniel Vetter wrote:
On Thu, May 3, 2018 at 5:04 PM, Sean Paul seanpaul@chromium.org wrote:
If you're still reading, I'll point out a couple other things:
- There is a bug tracker on the gitlab instance, feel free to add bugs/features/etc to it.
- I've added a TODO list to the wiki, but in typing this, realized
it's probably
better to file bugs for each item. So please ignore the TODO wiki
entry.
Any plans to wire up autobuilder or maybe even functional CI to the gitlab instance? That's where stuff gets really cool (and I think a lot of people will see the value of abandoning dri-devel much more, beyond the better S/N ratio).
Not as far as I know. A fun afternoon project might be to hook up
clang-format
verification as a merge request hook. Aside from that, I think proper
(or even
improper/simple) CI would require more effort than we have resources.
That should be pretty easy as a .gitlab-ci.yml. I'm working on getting support for qemu into the existing runner that we have, so it would be entirely possible to run a drm-hwc on a 'real' kernel, if you have something you can test under qemu.
I'm currently working on getting something like this up and running for normal feature development on my local machine.
That being said AOSP is a fast moving target. So we would have to pin the AOSP version and maybe bump it every year or so. I guess that goes for the kernel,mesa & libdrm as well.
Rob.
For on-hardware testing (e.g. run it on freedreno + vc4 + ...), that's a whole other topic that we don't currently cover.
Cheers, Daniel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, May 04, 2018 at 05:19:50PM +0000, Mauro Rossi wrote:
Hi all,
I just wanted to share that I'm conducting "newbie" tests on oreo-x86 with drm_hwcomposer, gbm_gralloc and libdrm with latest gralloc_handle.h
and the results are good on nouveau, provided that some changes in drmresources are applied to avoid throwing errors for non connected connectors,
i965 completes bootanimation, but surfaceflinger is killed when trying to draw status bar and menu bar (annoying but true)
amdgpu (bonaire which supports atomic drm) is affected by problems in setting the correct mode on display (only txt cursor is shown) and there are SIGSEGV MAPERR at libskia trying to draw pixels.
There are also errors logged by drm_hwcomposer code, which I'm not much able to interpret/analyze correctly.
I would like to open issues on drm_hwcomposer with the details and logs when I encounter them, may I use gitlab or bugzilla for these drm_hwcomposer specific issues?
Yes please! Feel free to file them via gitlab.
Thanks for instructions
Another question is for Intel and Chromeos developers: are you planning to update your minigbm projects to the new common gralloc_handle.h handle structure in latest libdrm?
I assume yes, but I'm not hooked in to what's happening with minigbm.
I'm asking because freedesktop drm_hwcomposer (hwctwo) moved to new libdrm gralloc_handle.h handle and it would make sense for minigbm to evolve accordingly,
and I'd like to try them in oreo-x86 as a like-for-like replacement option for gbm_gralloc
Did you see the latest patches from Alistair Strachan to add minigbm as a supported platform? That might do what you want.
Thanks for testing, it's much appreciated.
Sean
Thank for any info
Mauro Rossi
Il 04 mag 2018 14:48, "Robert Foss" robert.foss@collabora.com ha scritto:
Heya,
On 2018-05-04 12:51, Daniel Stone wrote:
Hi,
On 3 May 2018 at 20:12, Sean Paul seanpaul@chromium.org wrote:
On Thu, May 03, 2018 at 08:30:18PM +0200, Daniel Vetter wrote:
On Thu, May 3, 2018 at 5:04 PM, Sean Paul seanpaul@chromium.org wrote:
If you're still reading, I'll point out a couple other things:
- There is a bug tracker on the gitlab instance, feel free to add bugs/features/etc to it.
- I've added a TODO list to the wiki, but in typing this, realized
it's probably
better to file bugs for each item. So please ignore the TODO wiki
entry.
Any plans to wire up autobuilder or maybe even functional CI to the gitlab instance? That's where stuff gets really cool (and I think a lot of people will see the value of abandoning dri-devel much more, beyond the better S/N ratio).
Not as far as I know. A fun afternoon project might be to hook up
clang-format
verification as a merge request hook. Aside from that, I think proper
(or even
improper/simple) CI would require more effort than we have resources.
That should be pretty easy as a .gitlab-ci.yml. I'm working on getting support for qemu into the existing runner that we have, so it would be entirely possible to run a drm-hwc on a 'real' kernel, if you have something you can test under qemu.
I'm currently working on getting something like this up and running for normal feature development on my local machine.
That being said AOSP is a fast moving target. So we would have to pin the AOSP version and maybe bump it every year or so. I guess that goes for the kernel,mesa & libdrm as well.
Rob.
For on-hardware testing (e.g. run it on freedreno + vc4 + ...), that's a whole other topic that we don't currently cover.
Cheers, Daniel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, May 4, 2018 at 10:35 AM Sean Paul seanpaul@chromium.org wrote:
On Fri, May 04, 2018 at 05:19:50PM +0000, Mauro Rossi wrote:
[snip]
Another question is for Intel and Chromeos developers: are you planning
to
update your minigbm projects to the new common gralloc_handle.h handle
structure in latest libdrm?
I assume yes, but I'm not hooked in to what's happening with minigbm.
+1. We can take this to another thread. The main issue is that minigbm assumes a 1:1 planes to handles paradigm, the new generic handle does not.
I'm asking because freedesktop drm_hwcomposer (hwctwo) moved to new libdrm
gralloc_handle.h handle and it would make sense for minigbm to evolve accordingly,
and I'd like to try them in oreo-x86 as a like-for-like replacement
option
for gbm_gralloc
Did you see the latest patches from Alistair Strachan to add minigbm as a supported platform? That might do what you want.
If we move to the common handle, my changes can be dropped. That's the goal, it's just not possible right now.
Il 04 mag 2018 19:51, "Alistair Strachan" astrachan@google.com ha scritto:
On Fri, May 4, 2018 at 10:35 AM Sean Paul seanpaul@chromium.org wrote:
On Fri, May 04, 2018 at 05:19:50PM +0000, Mauro Rossi wrote:
[snip]
Another question is for Intel and Chromeos developers: are you planning
to
update your minigbm projects to the new common gralloc_handle.h handle
structure in latest libdrm?
I assume yes, but I'm not hooked in to what's happening with minigbm.
+1. We can take this to another thread. The main issue is that minigbm assumes a 1:1 planes to handles paradigm, the new generic handle does not.
Thanks for the info
This allows testing an hwcomposer.minigbm (by just changing some makefile rules and build as separate project) separately from hwcomposer.drm In order to select hwcomposer.drm+gralloc.gbm vs hwcomposer.minigbm+gralloc.minigbm I use init.sh and a boot cmdline parameter.
When testing drm_hwcomposer+ (chromeos minigbm or intel minigbm) two week ago I was getting SIGABRT no suitable EGL config.
I will repeat tests with cros/gralloc_drm_handle.h handle now supported via platformminigbm on amdgpu (requires patch on minigbm), i965 and nouveau.
Mauro
Mauro
I'm asking because freedesktop drm_hwcomposer (hwctwo) moved to new libdrm
gralloc_handle.h handle and it would make sense for minigbm to evolve accordingly,
and I'd like to try them in oreo-x86 as a like-for-like replacement
option
for gbm_gralloc
Did you see the latest patches from Alistair Strachan to add minigbm as a supported platform? That might do what you want.
Thanks, they will suffice for now, however minigbm was now put in diverging track from common libdrm gralloc handle.
If we move to the common handle, my changes can be dropped. That's the goal, it's just not possible right now.
Were those the only specificity introduced in hwc?
Is there documentation on the differences in composition of planes among driver platforms?
Why is amdgpu the only platform (among the ones supporting atomic) for which drm mode setting is not working with hwc, is there some difference in amdgpu drm implementation? [Just a hint, I'll open bug on gitlab]
I'll keep an eye on AOSP minigbm, cros minigbm and intel minigbm to see if/when they'll be updated to use new gralloc handle.
Mauro
[Really taking this to another thread. Leaving CC as is for the time being.]
On Sat, May 5, 2018 at 4:16 AM Mauro Rossi issor.oruam@gmail.com wrote:
Il 04 mag 2018 19:51, "Alistair Strachan" astrachan@google.com ha scritto:
On Fri, May 4, 2018 at 10:35 AM Sean Paul seanpaul@chromium.org wrote:
On Fri, May 04, 2018 at 05:19:50PM +0000, Mauro Rossi wrote:
[snip]
Another question is for Intel and Chromeos developers: are you planning
to
update your minigbm projects to the new common gralloc_handle.h handle
structure in latest libdrm?
I assume yes, but I'm not hooked in to what's happening with minigbm.
+1. We can take this to another thread. The main issue is that minigbm assumes a 1:1 planes to handles paradigm, the new generic handle does not.
Thanks for the info
I'm personally skeptical about this, but adding Gurchetan, who is a better person to comment on this. My biggest concern is that it might not be possible to define a common handle that is really good for everyone. Also, since the handle would effectively be a stable ABI between independent components, changing it to accommodate for future features (or discovered issues ) would be problematic.
Generally we designed our graphics stack in Chrome OS / ARC++ in a way that does not rely on the handle struct at all, so that we are free to change the struct in any way we want in the future, without any compatibility concerns (such as plane layout isssue mentioned before).
For the needs of EGL and most of other consumers, we are doing well without any API extensions (most of the time we get some more complete struct, such as ANativeWindow(Buffer) and for ambiguous formats we adopted lock_ycbcr method).
Our hwcomposer is the only exception for which we added some perform calls to retrieve data such as HAL pixel format, width, height, stride and backing store (unique ID within some private namespace of the gralloc instance, having similar properties to GEM handle within one DRI FD).
Best regards, Tomasz
Hey Sean,
On 2018-05-03 17:04, Sean Paul wrote:
Hey all, Apologies for the direct ping. I've harvested your emails from drm_hwc git logs, and didn't want to leave anyone out. The good news is that your email address will forever be remembered in the annals of drm_hwcomposer!
Anyways, back to the point.
Now that we have our shiny freedesktop gitlab instance [1], we should really start using it to its fullest extent. This means 2 things:
1- When you send patches, please consider using gitlab merge requests instead of git send-email. This is not mandatory, but dri-devel is so busy, I want to make sure things aren't lost. Further, there might be some who are not interested in reading dri-devel *gasp*, but who are interested in drm_hwc. 2- If you're interested in being notified of merge requests (since dri-devel can not be cc'd), please consider clicking "Watch" on the project and choose your desired notification level.
About the above two points, maybe we could set up a dummy account that watches the gitlab project and sends notifications to the dri-devel list?
If you're still reading, I'll point out a couple other things:
- There is a bug tracker on the gitlab instance, feel free to add bugs/features/etc to it.
- I've added a TODO list to the wiki, but in typing this, realized it's probably better to file bugs for each item. So please ignore the TODO wiki entry.
I can confirm that the TODOs are now very neatly organized issues. Thanks for setting this up and sending out this ping.
Rob.
Hey all,
On 4 May 2018 at 09:43, Robert Foss robert.foss@collabora.com wrote:
On 2018-05-03 17:04, Sean Paul wrote:
Apologies for the direct ping. I've harvested your emails from drm_hwc git logs, and didn't want to leave anyone out. The good news is that your email address will forever be remembered in the annals of drm_hwcomposer!
Anyways, back to the point.
Now that we have our shiny freedesktop gitlab instance [1], we should really start using it to its fullest extent. This means 2 things:
1- When you send patches, please consider using gitlab merge requests instead of git send-email. This is not mandatory, but dri-devel is so busy, I want to make sure things aren't lost. Further, there might be some who are not interested in reading dri-devel *gasp*, but who are interested in drm_hwc. 2- If you're interested in being notified of merge requests (since dri-devel can not be cc'd), please consider clicking "Watch" on the project and choose your desired notification level.
About the above two points, maybe we could set up a dummy account that watches the gitlab project and sends notifications to the dri-devel list?
Yeah, we could do that.
If you're still reading, I'll point out a couple other things:
- There is a bug tracker on the gitlab instance, feel free to add bugs/features/etc to it.
- I've added a TODO list to the wiki, but in typing this, realized it's
probably better to file bugs for each item. So please ignore the TODO wiki entry.
I can confirm that the TODOs are now very neatly organized issues. Thanks for setting this up and sending out this ping.
I'm not a massive fan of the wikis, but you can use GItLab Pages to generate sites from whatever content in a repo: https://docs.gitlab.com/ee/user/project/pages/
Perhaps that would be a better way of dealing with it: have the content in the repo as rst or whatever, some kind of static-site generator, then you can have it available to view on drm-hwcomposer.fd.o.
Cheers, Daniel
On Fri, May 04, 2018 at 11:48:10AM +0100, Daniel Stone wrote:
Hey all,
On 4 May 2018 at 09:43, Robert Foss robert.foss@collabora.com wrote:
On 2018-05-03 17:04, Sean Paul wrote:
Apologies for the direct ping. I've harvested your emails from drm_hwc git logs, and didn't want to leave anyone out. The good news is that your email address will forever be remembered in the annals of drm_hwcomposer!
Anyways, back to the point.
Now that we have our shiny freedesktop gitlab instance [1], we should really start using it to its fullest extent. This means 2 things:
1- When you send patches, please consider using gitlab merge requests instead of git send-email. This is not mandatory, but dri-devel is so busy, I want to make sure things aren't lost. Further, there might be some who are not interested in reading dri-devel *gasp*, but who are interested in drm_hwc. 2- If you're interested in being notified of merge requests (since dri-devel can not be cc'd), please consider clicking "Watch" on the project and choose your desired notification level.
About the above two points, maybe we could set up a dummy account that watches the gitlab project and sends notifications to the dri-devel list?
Yeah, we could do that.
If you're still reading, I'll point out a couple other things:
- There is a bug tracker on the gitlab instance, feel free to add bugs/features/etc to it.
- I've added a TODO list to the wiki, but in typing this, realized it's
probably better to file bugs for each item. So please ignore the TODO wiki entry.
I can confirm that the TODOs are now very neatly organized issues. Thanks for setting this up and sending out this ping.
I'm not a massive fan of the wikis, but you can use GItLab Pages to generate sites from whatever content in a repo: https://docs.gitlab.com/ee/user/project/pages/
Perhaps that would be a better way of dealing with it: have the content in the repo as rst or whatever, some kind of static-site generator, then you can have it available to view on drm-hwcomposer.fd.o.
Ahhh, this is what I was looking for when I started using the wiki! I've been suffering remourse from moving the CONTRIBUTING file to the wiki. I was hoping it'd be more visible than the small "CONTRIBUTING" button, but it's really not.
I've filed https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/issues/9 to track.
Sean
Cheers, Daniel
On Fri, May 04, 2018 at 10:43:22AM +0200, Robert Foss wrote:
Hey Sean,
On 2018-05-03 17:04, Sean Paul wrote:
Hey all, Apologies for the direct ping. I've harvested your emails from drm_hwc git logs, and didn't want to leave anyone out. The good news is that your email address will forever be remembered in the annals of drm_hwcomposer!
Anyways, back to the point.
Now that we have our shiny freedesktop gitlab instance [1], we should really start using it to its fullest extent. This means 2 things:
1- When you send patches, please consider using gitlab merge requests instead of git send-email. This is not mandatory, but dri-devel is so busy, I want to make sure things aren't lost. Further, there might be some who are not interested in reading dri-devel *gasp*, but who are interested in drm_hwc. 2- If you're interested in being notified of merge requests (since dri-devel can not be cc'd), please consider clicking "Watch" on the project and choose your desired notification level.
About the above two points, maybe we could set up a dummy account that watches the gitlab project and sends notifications to the dri-devel list?
Ah, yeah, I didn't think about that. That could definitely work! I do wonder how many people care about drm_hwc on dri-devel, but we could spin up the dummy account and see who complains.
If you're still reading, I'll point out a couple other things:
- There is a bug tracker on the gitlab instance, feel free to add bugs/features/etc to it.
- I've added a TODO list to the wiki, but in typing this, realized it's probably better to file bugs for each item. So please ignore the TODO wiki entry.
I can confirm that the TODOs are now very neatly organized issues. Thanks for setting this up and sending out this ping.
fd.o was nice enough to let us dogfood gitlab first, so the least we could do is start using it properly :-)
Shout out to Stefan Schake who's merge request was the first one merged via the new flow. Honorable mention goes to Alex Gheorghe who submitted the first merge request, which unfortunately has been held up by my nitty ways :-(
Sean
Rob.
dri-devel@lists.freedesktop.org
-
Alistair Strachan -
Daniel Stone -
Daniel Vetter -
Mauro Rossi -
Robert Foss -
Sean Paul -
Tomasz Figa