When we come to assign_planes, try very hard to ignore views which are
only visible on other outputs, rather than forcibly moving them to the
primary plane, which causes damage all round and unnecessary repaints.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
Tested-by: Emre Ucan
Hi,
Another re-send after Pekka's comments on the modifiers patches. Patches
01-12 from the last series were merged after the last round.
Patch 1 is new; patches 2 and 3 were extracted from patches 5 and 6.
Patches 4-6 have otherwise seen changes after Pekka's review; all the
comments were
ARRAY_LENGTH returns a size_t; rather than casting its result to
int so we can compare to our signed index variable, just declare the
index as a compatible type in the first place.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
of sync.
Signed-off-by: Daniel Stone
---
shared/helpers.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/shared/helpers.h b/shared/helpers.h
index 46f745d1b..9ecc3c4e9 100644
--- a/shared/helpers.h
+++ b/shared/helpers.h
@@ -100,6 +100,31 @@ extern "C" {
Hi,
On Mon, 9 Jul 2018 at 11:08, Pekka Paalanen wrote:
> On Thu, 5 Jul 2018 18:16:41 +0100 Daniel Stone wrote:
> > The per-plane IN_FORMATS property adds information about format
> > modifiers; we can use these to both feed GBM with the set of modifiers
> > we want
Hi Pekka,
On Mon, 9 Jul 2018 at 10:39, Pekka Paalanen wrote:
> On Thu, 5 Jul 2018 18:16:40 +0100
> Daniel Stone wrote:
> > +/* XXX: TODO:
> > + *
> > + * Currently the buffer is rejected if any dmabuf attribute
> > + * flag is se
Hi,
On Mon, 9 Jul 2018 at 08:38, Daniel Vetter wrote:
> On Fri, Jul 06, 2018 at 04:43:09PM +0100, Mike Lothian wrote:
> > Any change of this moving to https or the gitlab instance where its on as
> > default?
>
> Moving all the drm repos over to gitlab is somewhere on the plans, but we
> need to
Hi Pekka,
On Fri, 6 Jul 2018 at 14:14, Pekka Paalanen wrote:
> On Thu, 5 Jul 2018 18:16:35 +0100 Daniel Stone wrote:
> > Use the new helper to populate the cursor state as well, with some
> > special-case handling to account for how we always upload a full-size
> > BO
Hey Emil,
On Fri, 6 Jul 2018 at 11:02, Emil Velikov wrote:
> On 5 July 2018 at 18:16, Daniel Stone wrote:
> > Use the extended GBM allocator interface to support modifiers and
> > multi-planar BOs.
>
> Instead of such lovely checks and multiple #ifdef blocks through in
&g
Hi Pekka,
On Fri, 6 Jul 2018 at 13:48, Pekka Paalanen wrote:
>
> On Thu, 5 Jul 2018 18:16:34 +0100
> Daniel Stone wrote:
> > + /* Check the view spans exactly the output size, calculated in the
> > + * logical co-ordinate space. */
> > + extent
are part of the KMS ABI. The atomic
path does not need any changes, since atomic uses routing and CRTC
active to determine the connector's power state, rather than a property.
Signed-off-by: Daniel Stone
Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/125
---
libweston/compositor-drm.c
Hey Jakob,
On Thu, 5 Jul 2018 at 14:32, Jakob Bornecrantz wrote:
> So from a VR compositor getting blocked like this is a no-go as the
> user would quickly throw EPUKE. The situation is compounded by the
> fact that the VR compositor has no idea what the display compositor is
> doing with
Hey Jakob,
On Thu, 5 Jul 2018 at 14:32, Jakob Bornecrantz wrote:
> So from a VR compositor getting blocked like this is a no-go as the
> user would quickly throw EPUKE. The situation is compounded by the
> fact that the VR compositor has no idea what the display compositor is
> doing with
Since we now incrementally test atomic state as we build it, we can
loosen restrictions on what we can do with planes, and let the kernel
tell us whether or not it's OK.
Signed-off-by: Daniel Stone
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 21 +
1 file changed
the filled-in co-ordinates, i.e.
that we're not trying to show an offset into the buffer, or to scale the
image.
An audit of the error paths found some places where we would leave a
plane state hanging; this makes them all consistent.
Signed-off-by: Daniel Stone
Tested-by: Emre Ucan
---
libweston
We currently do the same thing in two places, and will soon have a
third.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 91 --
1 file changed, 48 insertions(+), 43 deletions(-)
diff --git
Now that we can sensibly test proposed plane configurations with atomic,
sprites are not broken.
Signed-off-by: Daniel Stone
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/libweston/compositor
-by: Sergi Granell
Reviewed-by: Daniel Stone
Tested-by: Emre Ucan
---
configure.ac | 3 +
libweston/compositor-drm.c | 125 ++---
2 files changed, 119 insertions(+), 9 deletions(-)
diff --git a/configure.ac b/configure.ac
index ef55ace36..c550198ae
Use the same codepath, which has the added advantage of being able to
import dmabufs.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 53 ++
1 file changed, 13 insertions(+), 40 deletions
Add support for multiple modes: toggling whether or not the renderer
and/or planes are acceptable. This will be used to implement a smarter
plane-placement heuristic when we have support for testing output
states.
Signed-off-by: Daniel Stone
Tested-by: Emre Ucan
---
libweston/compositor-drm.c
In our new and improved helper to determine the src/dest values for a
buffer on a given plane, make sure we account for all buffer
transformations, including viewport clipping.
Rather than badly open-coding it ourselves, just use the helper which
does exactly this.
Signed-off-by: Daniel Stone
When we come to assign_planes, try very hard to ignore views which are
only visible on other outputs, rather than forcibly moving them to the
primary plane, which causes damage all round and unnecessary repaints.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
Tested-by: Emre Ucan
Return a pointer to the plane state, rather than indirecting via a
weston_plane.
Signed-off-by: Daniel Stone
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 71 +-
1 file changed, 39 insertions(+), 32 deletions(-)
diff --git a/libweston/compositor
The atomic API can allow us to test state before we apply it, to see if
it will be valid. Add support for this, which we will later use in
assign_planes to ensure our plane configuration is valid.
Signed-off-by: Daniel Stone
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 176
When trying to assign planes, keep track of the areas which are
already occluded, and ignore views which are completely occluded. This
allows us to build a state using planes only, when there are occluded
views which cannot go into a plane behind views which can.
Signed-off-by: Daniel Stone
Move drm_assign_planes into two functions: one which proposes a plane
configuration, and another which applies that state to the Weston
internal structures. This will be used to try multiple configurations
and see which is supported.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
Use the extended GBM allocator interface to support modifiers and
multi-planar BOs.
Signed-off-by: Daniel Stone
Tested-by: Emre Ucan
---
configure.ac | 3 ++
libweston/compositor-drm.c | 61 +++---
2 files changed, 53 insertions(+), 11 deletions
... in order to be able to use it from scanout as well.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 225 -
1 file changed, 122 insertions(+), 103 deletions(-)
diff --git a/libweston
Put some more transformation checks in drm_view_transform_supported.
Signed-off-by: Daniel Stone
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 54 --
1 file changed, 34 insertions(+), 20 deletions(-)
diff --git a/libweston/compositor-drm.c b
Hi,
This is v16 (this time for sure) of the atomic series.
Patches 1 and 2 are new, falling out of previous review.
Patch 5 is a bit less trusting, and now properly clips to CRTC bounds if
required.
Similarly, I've gone through patch 8 and am more confident that it
actually does the right thing
-by: Daniel Stone
Reported-by: Derek Foreman
Tested-by: Emre Ucan
Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/118
---
libweston/compositor-drm.c | 68 ++
1 file changed, 32 insertions(+), 36 deletions(-)
diff --git a/libweston/compositor-drm.c
Add support for the GBM_BO_IMPORT_FD_MODIFIER path, which allows us to
import multi-plane dmabufs, as well as format modifiers.
Signed-off-by: Daniel Stone
Tested-by: Emre Ucan
---
configure.ac | 6 +-
libweston/compositor-drm.c | 181 +++--
2
Since it doesn't write to the parameter, we can make it const.
Signed-off-by: Daniel Stone
---
libweston/compositor-drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index b96e29671..c6b82ac44 100644
--- a/libweston
commit adds this checking inside prepare_scanout_view: if the
pending output state already has a framebuffer assigned to the scanout
plane, we drop out of prepare_scanout_view early. The picked_scanout
variable inside assign_planes can thus be removed.
Signed-off-by: Daniel Stone
Tested-by: Emre
Use the new drmModeAddFB2WithModifiers interface to import buffers with
modifiers.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
Tested-by: Emre Ucan
---
configure.ac | 3 +++
libweston/compositor-drm.c | 26 +-
2 files changed, 28 insertions
Pull this into a helper function, so we can use it everywhere.
Signed-off-by: Daniel Stone
Reviewed-by: Pekka Paalanen
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 162 +
1 file changed, 93 insertions(+), 69 deletions(-)
diff --git a/libweston
GBM BO dereference into a
different failure path, before it gets captured by the plane state.
Signed-off-by: Daniel Stone
Tested-by: Emre Ucan
---
libweston/compositor-drm.c | 118 ++---
1 file changed, 45 insertions(+), 73 deletions(-)
diff --git a/libwes
Hi Pekka,
On Tue, 30 Jan 2018 at 09:58, Pekka Paalanen wrote:
> On Wed, 20 Dec 2017 12:26:58 +
> Daniel Stone wrote:
> > + for (i = 0; i < plane->count_formats; i++) {
> > + if (plane->formats[i].format == output->gbm_format)
>
iver usage. Due to currently
> only out of tree lima driver need it, and not sure if this is
> the right way to disable it, so I send this RFC before lima be
> able to upstream.
Series is:
Acked-by: Daniel Stone
Cheers,
Daniel
___
mesa-d
Hi,
The atomic API being super-explicit about how userspace sequences its
calls is great and all, but having shared global state implicitly
dragged in is kind of ruining my day.
Currently on Intel, Weston sometimes fails on hotplug, because a
commit which only enables CRTC B (not touching CRTC A
Hi,
The atomic API being super-explicit about how userspace sequences its
calls is great and all, but having shared global state implicitly
dragged in is kind of ruining my day.
Currently on Intel, Weston sometimes fails on hotplug, because a
commit which only enables CRTC B (not touching CRTC A
Hi Russell,
On Tue, 26 Jun 2018 at 15:49, Russell King - ARM Linux
wrote:
> On Thu, May 17, 2018 at 04:41:35PM +0100, Daniel Stone wrote:
> > Thanks Russell. I did do a build test locally as well which had no
> > complaints. I'll merge this through drm-misc.
>
> I've not s
s to why we add ncrtc
twice (for the primary plane). But, with that (and no need to pass it
through the list again):
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/x
atomic, then we
> won't have selected a plane for each crtc, and this will break lease
> creation which requires planes for each output when universal_planes
> is enabled.
Reviewed-by: Daniel Stone
___
xorg-devel@lists.x.org: X.Org development
Arch
Hey Lyude,
On Thu, 21 Jun 2018 at 00:13, Lyude Paul wrote:
> -/* Pixmaps with multi-planes/modifier are not supported in this
> interface */
> -if (ret != 1 || offsets[0] != 0) {
> -while (ret > 0)
> -close(fds[--ret]);
> +ret = _glamor_fds_from_pixmap(screen,
Hi Dylan,
On Tue, 19 Jun 2018 at 16:42, Dylan Baker wrote:
> Historical artifact. When I created the proposed branch we didn't have a
> policy
> of putting it on master instead of a personal repo, and we were discussing a
> transition to gitlab. I also seem to remember that the gitlab doesn't
er or committer except me
> ever needed this.
>
> There's also no need to make sure drm-tip has all the right remotes
> nowadays, because that's all encoded in nightly.conf, and will be
> checked (if the remotes are missing) in dim_rebuild_tip.
Thanks D
Unbreak 'dim setup' and 'dim status' by noting the new repo name, as
configured in rerere config.
Signed-off-by: Daniel Stone
Cc: Daniel Vetter
---
dim | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/dim b/dim
index 1d562aa2360c..7092cd97b284 100755
--- a/dim
+++ b
Hi Pekka,
On Mon, 18 Jun 2018 at 15:41, Pekka Paalanen wrote:
> these changes are intended to make using Meson easier. Daniel's patches
> are v2, mine are v1.
>
> Daniel Stone (2):
> tests: Don't rely on build directory layout
> tests: Reshuffle IVI layout tests
>
appy to take alternate wording, since what you've written here is
far more concise than mine. Anyway, both patches are:
Reviewed-by: Daniel Stone
Could this later be used as the basis for similar Weston patches?
Cheers,
Daniel
___
wayland-dev
Hi Pekka,
On Wed, 13 Jun 2018 at 14:33, Pekka Paalanen wrote:
> Gitlab expects a CONTRIBUTING.md in the root directory, so move our
> guide there.
>
> Conversion to proper markup is a follow-up patch.
Thanks for these; both series are:
Reviewed-by: Daniel Stone
Ch
Hi Felix,
On Wed, 13 Jun 2018 at 10:24, Felix Miata wrote:
> Daniel Stone composed on 2018-06-13 09:24 (UTC+0100):
> > Felix Miata wrote:
> >> James Cloos composed on 2018-06-12 17:38 (UTC-0400):
> >> > BZ is superior to GL (or GH or the like).
>
> >>
Hi Felix,
On Wed, 13 Jun 2018 at 04:17, Felix Miata wrote:
> James Cloos composed on 2018-06-12 17:38 (UTC-0400):
> > Two comments:
>
> > BZ is superior to GL (or GH or the like).
>
> Strongly agree, especially for returning useful search results!!!
What kind of searches have you tried which
On Tue, 12 Jun 2018 at 22:36, James Cloos wrote:
> >>>>> "DS" == Daniel Stone writes:
> DS> No need to test; it's guaranteed to fail since we require Recaptcha
> DS> for login due to massive spam issues.
>
> Which is of course grossly unethical a
Hi Alexander,
On 12 June 2018 at 14:53, Alexander E. Patrakov wrote:
> Daniel Stone :
>> > That said, I could not even create an account with a noscript/xhtml basic
>> > browser (if you want to test that, install the famous noscript module with
>> > an
>
Hi Alexander,
On 12 June 2018 at 14:53, Alexander E. Patrakov wrote:
> Daniel Stone :
>> > That said, I could not even create an account with a noscript/xhtml basic
>> > browser (if you want to test that, install the famous noscript module with
>> > an
>
Hi Sylvain,
On 12 June 2018 at 13:38, wrote:
> On Tue, Jun 12, 2018 at 12:34:31PM +0100, Daniel Stone wrote:
>> GitLab has a pretty comprehensive and well-documented API which might
>> help if you don't want to use a web browser. There are also clients
>> like 'lab
Hi Sylvain,
On 12 June 2018 at 13:38, wrote:
> On Tue, Jun 12, 2018 at 12:34:31PM +0100, Daniel Stone wrote:
>> GitLab has a pretty comprehensive and well-documented API which might
>> help if you don't want to use a web browser. There are also clients
>> like 'lab
Hi Michel,
On 11 June 2018 at 11:33, Michel Dänzer wrote:
> On 2018-06-08 08:08 PM, Adam Jackson wrote:
>> I'd like us to start moving repos and bug tracking into gitlab.
>> Hopefully everyone's aware that gitlab exists and why fdo projects are
>> migrating to it. If not, the thread about Mesa's
Hi Sylvain,
It looks like Mutt is mangling email addresses - I've fixed Michel's.
On 11 June 2018 at 14:30, wrote:
> On Mon, Jun 11, 2018 at 12:33:52PM +0200, Michel Dänzer wrote:
>> Adding the amd-gfx list, in cases somebody there has concerns or other
>> feedback.
>
> For feedback:
> I
Hi Michel,
On 11 June 2018 at 11:33, Michel Dänzer wrote:
> On 2018-06-08 08:08 PM, Adam Jackson wrote:
>> I'd like us to start moving repos and bug tracking into gitlab.
>> Hopefully everyone's aware that gitlab exists and why fdo projects are
>> migrating to it. If not, the thread about Mesa's
Hi Sylvain,
It looks like Mutt is mangling email addresses - I've fixed Michel's.
On 11 June 2018 at 14:30, wrote:
> On Mon, Jun 11, 2018 at 12:33:52PM +0200, Michel Dänzer wrote:
>> Adding the amd-gfx list, in cases somebody there has concerns or other
>> feedback.
>
> For feedback:
> I
On 9 June 2018 at 00:11, Eric Anholt wrote:
> Adam Jackson writes:
>> I'd like us to start moving repos and bug tracking into gitlab.
>> Hopefully everyone's aware that gitlab exists and why fdo projects are
>> migrating to it. If not, the thread about Mesa's migration provides
>> some useful
I believe there are a few BSPs based on Pyro and earlier still, but
they would be pretty trivial bumps to include if vendors want to
upgrade Weston.
Either patch is:
Acked-by: Daniel Stone
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists
Hi,
On 4 June 2018 at 09:05, Daniel Stone wrote:
> On 29 May 2018 at 10:59, Daniel Stone wrote:
>> I would like to get the issues migrated as well. In order to do that
>> though, we need some more fixes to the 'bztogl' migration tool we've
>> been using to push issues fr
Update issue report and build instruction URLs for moving to GitLab, and
for everything having been HTTPS-only for quite some time.
Signed-off-by: Daniel Stone
---
README | 4 ++--
configure.ac | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/README b/README
index
Update bug and Git URLs for GitLab; the site has also been served over
HTTPS for quite some time.
Signed-off-by: Daniel Stone
---
README | 4 ++--
configure.ac | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/README b/README
index 63ffa31d..3ae9f0fc 100644
(In reply to Daniel Stone from comment #191)
> Another, probably better, way to do it would be to define a new flag like
> XkbSA_HasGroupFlags inside the XkbModAction flags field when group_flags and
> group_XXX are valid rather than potentially garbage. That would avoid the
> w
(In reply to Andreas Wettstein from comment #190)
> No news since. Apart from the formal proposal, there are some old patches
> for its implementation:
> https://lists.x.org/archives/xorg-devel/2012-November/034427.html
> https://lists.x.org/archives/xorg-devel/2012-November/034430.html
>
(In reply to Kovács Viktor from comment #181)
> Sorry, on newer Linux you can set up hot key combination for that problem as
> graphical UI settings, older Linux versions will not be updated. May I close
> It?
Please do not close this bug. If you do not want to receive any further
updates on it,
(In reply to Daniel Stone from comment #191)
> Another, probably better, way to do it would be to define a new flag like
> XkbSA_HasGroupFlags inside the XkbModAction flags field when group_flags and
> group_XXX are valid rather than potentially garbage. That would avoid the
> w
(In reply to Andreas Wettstein from comment #190)
> No news since. Apart from the formal proposal, there are some old patches
> for its implementation:
> https://lists.x.org/archives/xorg-devel/2012-November/034427.html
> https://lists.x.org/archives/xorg-devel/2012-November/034430.html
>
(In reply to Kovács Viktor from comment #181)
> Sorry, on newer Linux you can set up hot key combination for that problem as
> graphical UI settings, older Linux versions will not be updated. May I close
> It?
Please do not close this bug. If you do not want to receive any further
updates on it,
(In reply to Daniel Stone from comment #191)
> Another, probably better, way to do it would be to define a new flag like
> XkbSA_HasGroupFlags inside the XkbModAction flags field when group_flags and
> group_XXX are valid rather than potentially garbage. That would avoid the
> w
(In reply to Andreas Wettstein from comment #190)
> No news since. Apart from the formal proposal, there are some old patches
> for its implementation:
> https://lists.x.org/archives/xorg-devel/2012-November/034427.html
> https://lists.x.org/archives/xorg-devel/2012-November/034430.html
>
(In reply to Kovács Viktor from comment #181)
> Sorry, on newer Linux you can set up hot key combination for that problem as
> graphical UI settings, older Linux versions will not be updated. May I close
> It?
Please do not close this bug. If you do not want to receive any further
updates on it,
(In reply to Daniel Stone from comment #191)
> Another, probably better, way to do it would be to define a new flag like
> XkbSA_HasGroupFlags inside the XkbModAction flags field when group_flags and
> group_XXX are valid rather than potentially garbage. That would avoid the
> w
(In reply to Kovács Viktor from comment #181)
> Sorry, on newer Linux you can set up hot key combination for that problem as
> graphical UI settings, older Linux versions will not be updated. May I close
> It?
Please do not close this bug. If you do not want to receive any further
updates on it,
(In reply to Andreas Wettstein from comment #190)
> No news since. Apart from the formal proposal, there are some old patches
> for its implementation:
> https://lists.x.org/archives/xorg-devel/2012-November/034427.html
> https://lists.x.org/archives/xorg-devel/2012-November/034430.html
>
Hi Emil,
I replied to the rest further down-thread, but:
On 6 June 2018 at 15:33, Emil Velikov wrote:
> On 5 June 2018 at 23:06, Daniel Stone wrote:
>> + - git clone --depth=1
>> git://anongit.freedesktop.org/git/wayland/wayland-protocols
>> + - export WAYLAND_PROTOCO
Hi,
On 6 June 2018 at 16:41, Emil Velikov wrote:
> On 6 June 2018 at 15:47, Simon McVittie wrote:
>> On Wed, 06 Jun 2018 at 15:33:13 +0100, Emil Velikov wrote:
>>> On 5 June 2018 at 23:06, Daniel Stone wrote:
>>> > + - apt-get -y --no-install-recommends in
Hi Pekka,
On 7 June 2018 at 08:46, Pekka Paalanen wrote:
> On Wed, 6 Jun 2018 15:37:01 +0100
> Emil Velikov wrote:
>> On 6 June 2018 at 09:56, Pekka Paalanen wrote:
>> > On Wed, 6 Jun 2018 09:22:59 +0100
>> > Daniel Stone wrote:
>> >> On 6 June 2018 a
Hi,
On 2 June 2018 at 16:45, Jason Ekstrand wrote:
> When the migration happens, there will be a very brief (less than 30
> minutes?) period during which no one will be able to push to either repo.
> I'll fire off an e-mail as well as messages in #dri-devel and #intel-3d
> shortly before we
Hi Emil,
On 5 June 2018 at 18:21, Emil Velikov wrote:
> On 5 June 2018 at 18:02, Daniel Stone wrote:
>>>> drm-gralloc.git
> Empty - please nuke, alongside bugzilla & other infra.
Done.
>>>> drm.git
> Out of curiosity - this and others (say igt) projects
On 6 June 2018 at 20:56, Adam Jackson wrote:
> This was left disabled in 1.20.0, it's time to start being sure it
> works.
>
> Signed-off-by: Adam Jackson
Acked-by: Daniel Stone
___
xorg-devel@lists.x.org: X.Org development
Ar
f
> 255. This doesn't set the "high_keycode_warned" on purpose so we get this for
> the first key that actually matters.
Reviewed-by: Daniel Stone
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
I
We definitely do, but I assume it's not been tested recently ...
(Sorry about mangled formatting)
On Wed, 6 Jun 2018, 8:42 pm Jason Ekstrand, wrote:
> On June 6, 2018 12:37:58 Daniel Stone wrote:
>
>> Right, it's a feature we use, because we do all import them as separate
Right, it's a feature we use, because we do all import them as separate
EGLImages ... and we won't if it's not advertised.
On Wed, 6 Jun 2018, 7:05 pm Jason Ekstrand, wrote:
> On Wed, Jun 6, 2018 at 11:03 AM, Jason Ekstrand
> wrote:
>
>> On Wed, Jun 6, 2018 at 11:00 AM, Daniel
Sorry, but as written this will regress ability to import NV12 images as
separately-addressed planes with shader conversion to RGB; Kodi, Mutter and
Weston all use this.
On Wed, 6 Jun 2018, 6:48 pm Jason Ekstrand, wrote:
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>
Hi,
On 6 June 2018 at 04:50, Dave Airlie wrote:
> First up I've moved the drm tree to a new location on freedesktop.org. The
> main
> reason was to explore using Daniel's maintainer tools (dim-tools) to manage
> pull requests and possibly open the drm to having co-maintainers at the top
> level
Hi,
On 6 June 2018 at 09:03, Pekka Paalanen wrote:
> On Tue, 5 Jun 2018 23:06:59 +0100
> Daniel Stone wrote:
>> + - export XDG_RUNTIME_DIR="$(mktemp -p $(pwd) -d xdg-runtime-XX)"
>> + - export BUILD_ID="weston-$CI_JOB_NAME_$CI_COMMIT_SHA-$CI_JOB_ID"
Hi Kevin,
On 5 June 2018 at 23:37, Kevin Brace wrote:
> I did ask freedesktop.org to grant me commit privilege to xf86-video-* DDX
> repositories, but I have yet to hear from them.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=106605
For accounts, freedesktop.org are just a very low-value
Signed-off-by: Daniel Stone
---
.gitlab-ci.yml | 48
1 file changed, 48 insertions(+)
create mode 100644 .gitlab-ci.yml
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
new file mode 100644
index 0..202fa5494
--- /dev/null
+++ b/.gitlab
Just in case we're running on something quite old.
Signed-off-by: Daniel Stone
---
clients/simple-dmabuf-drm.c | 4
1 file changed, 4 insertions(+)
diff --git a/clients/simple-dmabuf-drm.c b/clients/simple-dmabuf-drm.c
index df96758c9..fcab30e5c 100644
--- a/clients/simple-dmabuf-drm.c
Signed-off-by: Daniel Stone
---
.gitlab-ci.yml | 34 ++
1 file changed, 34 insertions(+)
create mode 100644 .gitlab-ci.yml
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
new file mode 100644
index ..ce23cf3e
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,34
On 5 June 2018 at 17:55, Eric Engestrom wrote:
> On Tuesday, 2018-06-05 17:52:17 +0100, Daniel Stone wrote:
>> > I assume that's now mesa, libdrm, piglit, shader-db, crucible, kmscube,
>> > mesa-demos; what about igt? Anything else?
>>
>> We currently ha
Hi Eric,
On 5 June 2018 at 17:49, Eric Engestrom wrote:
> On Tuesday, 2018-06-05 09:11:58 -0700, Jason Ekstrand wrote:
>> Given the discussion below, I think we'll make piglit a sub-project of
>> mesa. Those who need commit access to piglit but not mesa can be added
>> directly to the piglit
Hi Juan,
On 5 June 2018 at 09:51, Juan A. Suarez Romero wrote:
> On Mon, 2018-06-04 at 13:22 +0100, Daniel Stone wrote:
>> The first query will correctly return (w1,h1). The second query will
>> incorrectly also return (w1,h1), even though the surface will never
>> have
Hi Erik,
On 31 May 2018 at 09:36, Erik De Rijcke wrote:
> First of all I'd like to say that the move to Gitlab makes me really happy
> \o/! It will definitely lower the contribution barrier for a lot of people
> (including me!) as things are now far more accessible, visible and overall
> easier
Hi,
On 4 June 2018 at 13:14, Daniel Stone wrote:
> On 4 June 2018 at 12:29, Pekka Paalanen wrote:
>> Does it clash with the GitLab migration?
>
> We've already moved the repos and the site. I think it would be good
> to move our issues just before the release, so by 5.0.0rc (
801 - 900 of 9461 matches
Mail list logo
