Re: Requiring newer autoconf for X.Org packages?

[Daniel Stone]

Hi,

On Tue, 30 Aug 2022 at 22:42, Alan Coopersmith 
wrote:

> We document autoconf 2.62 as the minimum release required in:
> https://www.x.org/wiki/Building_the_X_Window_System/
> and most modules have AC_PREREQ([2.60]).  If I recall correctly, a decade
> ago
> we didn't want to force use of autoconf 2.65 or later since some vendors
> were
> still uncertain at that time about those newer version being under GPLv3 -
> is
> that still a problem for anyone?


GPLv3 is still a huge no-go for a fair few vendors I know of. If you look
around various product source drops, you can generally use shipping bash
3.2.x as a proxy for this.

I don't think this is a huge deal though; for xserver they're all using
Meson + Xwayland (if at all), and for the libs they can either rebuild with
older autotools (if it's still compatible), or just stick with an older
version and forego the torrent of forthcoming improvements in those
codebases.

Cheers,
Daniel

Re: 504 to gitlab.freedesktop.org

[Daniel Stone]

Hi,

On Mon, 13 Jun 2022 at 08:39, Daniel Stone  wrote:
> Yes, that's what's happening. Our (multi-host-replicated etc) Ceph
> storage setup has entered a degraded mode due to the loss of a couple
> of disks - no data has been lost but the cluster is currently unhappy.
> We're walking through fixing this, but have bumped into some other
> issues since, including a newly-flaky network setup, and changes since
> we last provisioned a new storage host.
>
> We're working through them one by one and will have the service back
> up with all our data intact - hopefully in a matter of hours but we
> have no firm ETA right now.

Thanks mainly to Ben, everything is back up and running now.

Cheers,
Daniel

Re: 504 to gitlab.freedesktop.org

[Daniel Stone]

On Mon, 13 Jun 2022 at 05:17, Peter Hutterer  wrote:
> On Sun, Jun 12, 2022 at 05:57:05PM -0700, Jeremy Sequoia wrote:
> > I was going to spend a little bit of time putting out an update to XQuartz
> > to address a few bugs that I've been meaning to squash, but I'm having a bit
> > of an issue pulling down sources.
> >
> > Fetching via ssh://g...@gitlab.freedesktop.org is giving me Permission 
> > denied
> > (publickey,keyboard-interactive).  I'm not sure if the latter is an infra
> > issue or if the ssh key I have stored in my gitlab account are out of date
> > (it's been about a year since I touched this).  Unfortunately, I can't seem
> > to access https://gitlab.freedesktop.org to check as it's constantly
> > presenting me a 504 Gateway timeout.
> >
> > Is anyone else able to pull sources via ssh://g...@gitlab.freedesktop.org
> > right now?  Is someone looking into the 504 issue?
>
> not an fdo admin but judging by the chatter on #freedesktop: no and yes, in
> that order. seems like the infrastructure is in various stages of depositing
> fecal matter on itself and the fixes are involved enough that the admins have
> to be mentally awake, not merely physically.

Yes, that's what's happening. Our (multi-host-replicated etc) Ceph
storage setup has entered a degraded mode due to the loss of a couple
of disks - no data has been lost but the cluster is currently unhappy.
We're walking through fixing this, but have bumped into some other
issues since, including a newly-flaky network setup, and changes since
we last provisioned a new storage host.

We're working through them one by one and will have the service back
up with all our data intact - hopefully in a matter of hours but we
have no firm ETA right now.

Cheers,
Daniel

Re: Plumbing explicit synchronization through the Linux ecosystem

[Daniel Stone]

Hi Tomek,

On Mon, 16 Mar 2020 at 12:55, Tomek Bury  wrote:
> I've been wrestling with the sync problems in Wayland some time ago, but only 
> with regards to 3D drivers.
>
> The guarantee given by the GL/GLES spec is limited to a single graphics 
> context. If the same buffer is accessed by 2 contexts the outcome is 
> unspecified. The cross-context and cross-process synchronisation is not 
> guaranteed. It happens to work on Mesa, because the read/write locking is 
> implemented in the kernel space, but it didn't work on Broadcom driver, which 
> has read-write interlocks in user space.

GL and GLES are not relevant. What is relevant is EGL, which defines
interfaces to make things work on the native platform. EGL doesn't
define any kind of synchronisation model for the Wayland, X11, or
GBM/KMS platforms - but it's one of the things which has to work. It
doesn't say that the implementation must make sure that the requested
format is displayable, but you sort of take it for granted that if you
ask EGL to display something it will do so.

Synchronisation is one of those mechanisms which is left to the
platform to implement under the hood. In the absence of platform
support for explicit synchronisation, the synchronisation must be
implicit.

>  A Vulkan client makes it even worse because of conflicting requirements: 
> Vulkan's vkQueuePresentKHR() passes in a number of semaphores but disallows 
> waiting. Wayland WSI requires wl_surface_commit() to be called from 
> vkQueuePresentKHR() which does require a wait, unless a synchronisation 
> primitive representing Vulkan samaphores is passed between Vulkan client and 
> the compositor.

If you are using EGL_WL_bind_wayland_display, then one of the things
it is explicitly allowed/expected to do is to create a Wayland
protocol interface between client and compositor, which can be used to
pass buffer handles and metadata in a platform-specific way. Adding
synchronisation is also possible.

> The most troublesome part was Wayland buffer release mechanism, as it only 
> involves a CPU signalling over Wayland IPC, without any 3D driver 
> involvement. The choices were: explicit synchronisation extension or a buffer 
> copy in the compositor (i.e. compositor textures from the copy, so the client 
> can re-write the original), or some implicit synchronisation in kernel space 
> (but that wasn't an option in Broadcom driver).

You can add your own explicit synchronisation extension.

In every cross-process and cross-subsystem usecase, synchronisation is
obviously required. The two options for this are to implement kernel
support for implicit synchronisation (as everyone else has done), or
implement generic support for explicit synchronisation (as we have
been working on with implementations inside Weston and Exosphere at
least), or implement private support for explicit synchronisation, or
do nothing and then be surprised at the lack of synchronisation.

Cheers,
Daniel
___
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: Plumbing explicit synchronization through the Linux ecosystem

[Daniel Stone]

Hi,

On Mon, 16 Mar 2020 at 15:33, Tomek Bury  wrote:
> > GL and GLES are not relevant. What is relevant is EGL, which defines
> > interfaces to make things work on the native platform.
> Yes and no. This is what EGL spec says about sharing a texture between 
> contexts:

Contexts are different though ...

> There are similar statements with regards to the lack of
> synchronisation guarantees for EGL images or between GL and native
> rendering, etc.

This also isn't about native rendering.

> But the main thing here is that EGL and Vulkan differ
> significantly.

Sure, I totally agree.

> The eglSwapBuffers() is expected to post an unspecified
> "back buffer" to the display system using some internal driver magic.
> EGL driver is then expected to obtain another back buffer at some
> unspecified point in the future.

Yes, this is rather the point: EGL doesn't specify platform-related
'black magic' to make things just work, because that's part of the
platform implementation details. And, as things stand, on Linux one of
those things is implicit synchronisation, unless the desired end state
of your driver is no synchronisation.

This thread is a discussion about changing that.

> > If you are using EGL_WL_bind_wayland_display, then one of the things
> > it is explicitly allowed/expected to do is to create a Wayland
> > protocol interface between client and compositor, which can be used to
> > pass buffer handles and metadata in a platform-specific way. Adding
> > synchronisation is also possible.
> Only one-way synchronisation is possible with this mechanism. There's
> a standard protocol for recycling buffers - wl_buffer_release() so
> buffer hand-over from the compositor to client remains unsynchronised
> - see below.

That's not true; you can post back a sync token every time the client
buffer is used by the compositor.

> > > The most troublesome part was Wayland buffer release mechanism, as it 
> > > only involves a CPU signalling over Wayland IPC, without any 3D driver 
> > > involvement. The choices were: explicit synchronisation extension or a 
> > > buffer copy in the compositor (i.e. compositor textures from the copy, so 
> > > the client can re-write the original), or some implicit synchronisation 
> > > in kernel space (but that wasn't an option in Broadcom driver).
> >
> > You can add your own explicit synchronisation extension.
> I could but that requires implementing in in the driver and in a
> number of compositors, therefore a standard extension
> zwp_linux_explicit_synchronization_v1 is much better choice here than
> a custom one.

EGL_WL_bind_wayland_display is explicitly designed to allow each
driver to implement its own private extensions without modifying
compositors. For instance, Mesa adds the `wl_drm` extension, which is
used for bidirectional communication between the EGL implementations
in the client and compositor address spaces, without modifying either.

> > In every cross-process and cross-subsystem usecase, synchronisation is
> > obviously required. The two options for this are to implement kernel
> > support for implicit synchronisation (as everyone else has done),
> That would require major changes in driver architecture or a 2nd
> mechanisms doing the same thing but in kernel space - both are
> non-starters.

OK. As it stands, everyone else has the kernel mechanism (e.g. via
dmabuf resv), so in this case if you are reinventing the underlying
platform in a proprietary stack, you get to solve the same problems
yourselves.

Cheers,
Daniel
___
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: gitlab.fd.o financial situation and impact on services

[Daniel Stone]

Hi Jan,

On Fri, 28 Feb 2020 at 10:09, Jan Engelhardt  wrote:
> On Friday 2020-02-28 08:59, Daniel Stone wrote:
> >I believe that in January, we had $2082 of network cost (almost
> >entirely egress; ingress is basically free) and $1750 of
> >cloud-storage cost (almost all of which was download). That's based
> >on 16TB of cloud-storage (CI artifacts, container images, file
> >uploads, Git LFS) egress and 17.9TB of other egress (the web service
> >itself, repo activity). Projecting that out [×12 for a year] gives
> >us roughly $45k of network activity alone,
>
> I had come to a similar conclusion a few years back: It is not very
> economic to run ephemereal buildroots (and anything like it) between
> two (or more) "significant locations" of which one end is located in
> a Large Cloud datacenter like EC2/AWS/etc.
>
> As for such usecases, me and my surrounding peers have used (other)
> offerings where there is 50 TB free network/month, and yes that may
> have entailed doing more adminning than elsewhere - but an admin
> appreciates $2000 a lot more than a corporation, too.

Yes, absolutely. For context, our storage & network costs have
increased >10x in the past 12 months (~$320 Jan 2019), >3x in the past
6 months (~$1350 July 2019), and ~2x in the past 3 months (~$2000 Oct
2019).

I do now (personally) think that it's crossed the point at which it
would be worthwhile paying an admin to solve the problems that cloud
services currently solve for us - which wasn't true before. Such an
admin could also deal with things like our SMTP delivery failure rate,
which in the past year has spiked over 50% (see previous email),
demand for new services such as Discourse which will enable user
support without either a) users having to subscribe to a mailing list,
or b) bug trackers being cluttered up with user requests and other
non-bugs, etc.

Cheers,
Daniel
___
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: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Daniel Stone]

On Fri, 28 Feb 2020 at 10:06, Erik Faye-Lund
 wrote:
> On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote:
> > Yeah, changes on vulkan drivers or backend compilers should be
> > fairly
> > sandboxed.
> >
> > We also have tools that only work for intel stuff, that should never
> > trigger anything on other people's HW.
> >
> > Could something be worked out using the tags?
>
> I think so! We have the pre-defined environment variable
> CI_MERGE_REQUEST_LABELS, and we can do variable conditions:
>
> https://docs.gitlab.com/ee/ci/yaml/#onlyvariablesexceptvariables
>
> That sounds like a pretty neat middle-ground to me. I just hope that
> new pipelines are triggered if new labels are added, because not
> everyone is allowed to set labels, and sometimes people forget...

There's also this which is somewhat more robust:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2569

Cheers,
Daniel
___
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: [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Daniel Stone]

On Fri, 28 Feb 2020 at 08:48, Dave Airlie  wrote:
> On Fri, 28 Feb 2020 at 18:18, Daniel Stone  wrote:
> > The last I looked, Google GCP / Amazon AWS / Azure were all pretty
> > comparable in terms of what you get and what you pay for them.
> > Obviously providers like Packet and Digital Ocean who offer bare-metal
> > services are cheaper, but then you need to find someone who is going
> > to properly administer the various machines, install decent
> > monitoring, make sure that more storage is provisioned when we need
> > more storage (which is basically all the time), make sure that the
> > hardware is maintained in decent shape (pretty sure one of the fd.o
> > machines has had a drive in imminent-failure state for the last few
> > months), etc.
> >
> > Given the size of our service, that's a much better plan (IMO) than
> > relying on someone who a) isn't an admin by trade, b) has a million
> > other things to do, and c) hasn't wanted to do it for the past several
> > years. But as long as that's the resources we have, then we're paying
> > the cloud tradeoff, where we pay more money in exchange for fewer
> > problems.
>
> Admin for gitlab and CI is a full time role anyways. The system is
> definitely not self sustaining without time being put in by you and
> anholt still. If we have $75k to burn on credits, and it was diverted
> to just pay an admin to admin the real hw + gitlab/CI would that not
> be a better use of the money? I didn't know if we can afford $75k for
> an admin, but suddenly we can afford it for gitlab credits?

s/gitlab credits/GCP credits/

I took a quick look at HPE, which we previously used for bare metal,
and it looks like we'd be spending $25-50k (depending on how much
storage you want to provision, how much room you want to leave to
provision more storage later, how much you care about backups) to run
a similar level of service so that'd put a bit of a dint in your
year-one budget.

The bare-metal hosting providers also add up to more expensive than
you might think, again especially if you want either redundancy or
just backups.

> > Yes, we could federate everything back out so everyone runs their own
> > builds and executes those. Tinderbox did something really similar to
> > that IIRC; not sure if Buildbot does as well. Probably rules out
> > pre-merge testing, mind.
>
> Why? does gitlab not support the model? having builds done in parallel
> on runners closer to the test runners seems like it should be a thing.
> I guess artifact transfer would cost less then as a result.

It does support the model but if every single build executor is also
compiling Mesa from scratch locally, how long do you think that's
going to take?

> > Again, if you want everything to be centrally
> > designed/approved/monitored/controlled, that's a fine enough idea, and
> > I'd be happy to support whoever it was who was doing that for all of
> > fd.o.
>
> I don't think we have any choice but to have someone centrally
> controlling it, You can't have a system in place that lets CI users
> burn largs sums of money without authorisation, and that is what we
> have now.

OK, not sure who it is who's going to be approving every update to
every .gitlab-ci.yml in the repository, or maybe we just have zero
shared runners and anyone who wants to do builds can BYO.
___
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: [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Daniel Stone]

On Fri, 28 Feb 2020 at 03:38, Dave Airlie  wrote:
> b) we probably need to take a large step back here.
>
> Look at this from a sponsor POV, why would I give X.org/fd.o
> sponsorship money that they are just giving straight to google to pay
> for hosting credits? Google are profiting in some minor way from these
> hosting credits being bought by us, and I assume we aren't getting any
> sort of discounts here. Having google sponsor the credits costs google
> substantially less than having any other company give us money to do
> it.

The last I looked, Google GCP / Amazon AWS / Azure were all pretty
comparable in terms of what you get and what you pay for them.
Obviously providers like Packet and Digital Ocean who offer bare-metal
services are cheaper, but then you need to find someone who is going
to properly administer the various machines, install decent
monitoring, make sure that more storage is provisioned when we need
more storage (which is basically all the time), make sure that the
hardware is maintained in decent shape (pretty sure one of the fd.o
machines has had a drive in imminent-failure state for the last few
months), etc.

Given the size of our service, that's a much better plan (IMO) than
relying on someone who a) isn't an admin by trade, b) has a million
other things to do, and c) hasn't wanted to do it for the past several
years. But as long as that's the resources we have, then we're paying
the cloud tradeoff, where we pay more money in exchange for fewer
problems.

> If our current CI architecture is going to burn this amount of money a
> year and we hadn't worked this out in advance of deploying it then I
> suggest the system should be taken offline until we work out what a
> sustainable system would look like within the budget we have, whether
> that be never transferring containers and build artifacts from the
> google network, just having local runner/build combos etc.

Yes, we could federate everything back out so everyone runs their own
builds and executes those. Tinderbox did something really similar to
that IIRC; not sure if Buildbot does as well. Probably rules out
pre-merge testing, mind.

The reason we hadn't worked everything out in advance of deploying is
because Mesa has had 3993 MRs in the not long over a year since
moving, and a similar number in GStreamer, just taking the two biggest
users. At the start it was 'maybe let's use MRs if you want to but
make sure everything still goes through the list', and now it's
something different. Similarly the CI architecture hasn't been
'designed', so much as that people want to run dEQP and Piglit on
their hardware pre-merge in an open fashion that's actually accessible
to people, and have just done it.

Again, if you want everything to be centrally
designed/approved/monitored/controlled, that's a fine enough idea, and
I'd be happy to support whoever it was who was doing that for all of
fd.o.

Cheers,
Daniel
___
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: gitlab.fd.o financial situation and impact on services

[Daniel Stone]

Hi Matt,

On Thu, 27 Feb 2020 at 23:45, Matt Turner  wrote:
> We're paying 75K USD for the bandwidth to transfer data from the
> GitLab cloud instance. i.e., for viewing the https site, for
> cloning/updating git repos, and for downloading CI artifacts/images to
> the testing machines (AFAIU).

I believe that in January, we had $2082 of network cost (almost
entirely egress; ingress is basically free) and $1750 of cloud-storage
cost (almost all of which was download). That's based on 16TB of
cloud-storage (CI artifacts, container images, file uploads, Git LFS)
egress and 17.9TB of other egress (the web service itself, repo
activity). Projecting that out gives us roughly $45k of network
activity alone, so it looks like this figure is based on a projected
increase of ~50%.

The actual compute capacity is closer to $1150/month.

> I was not aware that we were being charged for anything wrt GitLab
> hosting yet (and neither was anyone on my team at Intel that I've
> asked). This... kind of needs to be communicated.
>
> A consistent concern put forth when we were discussing switching to
> GitLab and building CI was... how do we pay for it. It felt like that
> concern was always handwaved away. I heard many times that if we
> needed more runners that we could just ask Google to spin up a few
> more. If we needed testing machines they'd be donated. No one
> mentioned that all the while we were paying for bandwidth... Perhaps
> people building the CI would make different decisions about its
> structure if they knew it was going to wipe out the bank account.

The original answer is that GitLab themselves offered to sponsor
enough credit on Google Cloud to get us started. They used GCP
themselves so they could assist us (me) in getting bootstrapped, which
was invaluable. After that, Google's open-source program office
offered to sponsor us for $30k/year, which was I believe last April.
Since then the service usage has increased roughly by a factor of 10,
so our 12-month sponsorship is no longer enough to cover 12 months.

> What percentage of the bandwidth is consumed by transferring CI
> images, etc? Wouldn't 75K USD would be enough to buy all the testing
> machines we need and host them within Google or wherever so we don't
> need to pay for huge amounts of bandwidth?

Unless the Google Cloud Platform starts offering DragonBoards, it
wouldn't reduce our bandwidth usage as the corporate network is
treated separately for egress.

Cheers,
Daniel
___
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: Radeonhd repo not migrated to gitlab.

[Daniel Stone]

Hi Kevin,

On Wed, 13 Mar 2019 at 16:00, Kevin Brace  wrote:
> I am not here to side with either one of you (i.e., Luc or you), but I have 
> been wondering why some of the older, neglected (I use the word "underserved" 
> to describe it) DDXs in general have weird git and ssh clone addresses.
> For example, Number Nine Imagine 128 DDX.
>
> [...]
>
> Why do I see this xorg/xserver-test for xorg/driver/xf86-video-i128?
> Another example will be S3 ViRGE DDX.
>
> [...]
>
> This time I see xorg/driver/xf86-video-p690.
> I probably should not get into the conspiracy theory territory, but for 
> some of the underserved DDXs some months ago, the git and ssh cloning 
> addresses were definitely pointing to xorg/driver/xf86-video-radeonhd.
> It was about roughly when you were working on GitLab migration.
> Considering that the history between you and Luc, is there a good explanation 
> for why the cloning addresses for git and ssh were pointing to 
> xorg/driver/xf86-video-radeonhd back then?
> I have been wondering if this was some kind of a prank considering the 
> history of xf86-video-radeonhd.
> I do not have a personal stake in what happened between you and Luc some 
> years ago, but if you can try to correct the wrong git and ssh cloning 
> address issue, that will be appreciated.

Sure, I've fixed it now, though it might take a few minutes to finish updating.

In the shell script we use to generate cgitrc, we were looping over
all the repositories and either printing a GitLab clone URL if the
tree was mirrored from GitLab to cgit, or printing anongit clone URLs
if not. In the former case, we were forgetting to clear the variables
with the anongit URLs, so GitLab repos would show the anongit clone
URLs of the last non-GitLab repo found (if any).

Hence xf86-video-radeonhd appearing in some drivers (as it was
inadvertently missed until this thread), xserver-test appearing in
others (as it was deliberately not migrated), and xf86-video-p690 (not
migrated as it's empty).

I've attached the relevant shell snippet in order to hopefully calm
the conspiracy theories.

In future, if you notice anything like this, please file an issue on
https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/new/ and
we'll try to fix it.

Cheers,
Daniel


gitlab_mirror=$(test -d /git/${sh_wgit} && pushd
/git/${sh_wgit} >/dev/null && git config --local fdo.gitlab-mirror ||
true)
if [ -n "$gitlab_mirror" ]; then
httpsurl="https://gitlab.freedesktop.org/$gitlab_mirror;
sshurl="" # XXX this was missing
giturl="" # XXX this was missing
httpurl="" # XXX this was missing
echo "repo.desc=$desc (mirrored from $httpsurl)"
else
httpsurl=""
echo repo.desc=$desc
if [ "${url#\~}" != "$url" ]; then
sshurl="ssh://people.freedesktop.org/$url"
giturl="git://people.freedesktop.org/$url"
else
sshurl="ssh://git.freedesktop.org/git/$url"
giturl="git://anongit.freedesktop.org/$url"
fi
fi

echo "repo.clone-url=$httpsurl $giturl $sshurl $httpurl"
___
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: Radeonhd repo not migrated to gitlab.

[Daniel Stone]

On Fri, 8 Mar 2019 at 10:52, Luc Verhaegen  wrote:
> A quick look over other
> requests back then showed me that it usually took you many days, often
> weeks, to answer new project requests. But when _i_ asked, a not too
> supportive reply was quickly received.

I've snipped most of the misleading accounts of history, incorrect or
invented events, and pure outright defamatory lies that you've spent
the last ten years posting all over the internet. There's no point in
responding to them since you just go silent, then pop up six months or
a year later to tell a new set of people the same old set of garbage,
in the hope of destroying peoples' reputations and/or careers.

I thought that after some pretty civil interactions recently, and
quickly and reasonably responding to your request for help with an
explanation of why the mistake happened in the first place, that there
was no danger here. But nope, after spending ten years tip-toeing
around you, ignoring all the bait in the form of lies and defaming my
character and motivations, but also trying to be 'fair' to the
community by spending my time actioning your requests like the above,
that's my reward.

So here's my new and clear policy on Luc Verhaegen: I'm never in my
life dealing with you again. If you ask for help or in fact any of my
time, in any forum at all (e.g. here, sitewranglers@, IRC, whatever),
I'm ignoring it. Even if I am literally the only person who can do the
thing you ask for, whatever that is, I will flatly refuse to do it. If
you file an issue which requires my action specifically, it will get
immediately closed.

> Integrity is such a nice word. Somehow it feels like words like
> integrity and custodian belong together.

Given all your vindictive and abusive bullying over many years, I
wouldn't if I were you choose 'personal and professional integrity' to
judge others on.
___
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: Radeonhd repo not migrated to gitlab.

[Daniel Stone]

On Fri, 8 Mar 2019 at 10:15, Luc Verhaegen  wrote:
> On Fri, Mar 08, 2019 at 10:12:17AM +0900, Daniel Stone wrote:
> > I'll admit that somewhere between writing migration scripts, migrating
> > the other 1,268 repos from git.fd.o, maintaining our new and old
> > infrastructure, trying to find financial sponsorship for our
> > infrastructure, fire-fighting sudden 50% SMTP delivery failure rates,
> > bringing up a CI system and maintaining it as it exploded in use,
> > supporting people trying to use our new systems by walking them
> > through the API and bug-hunting for them, documenting and scripting
> > our new infrastructure so it can be replicated, dealing with regular
> > influxes of Bugzilla spam, trying to urgently move everyone off
> > Bugzilla as it's now abandoned upstream, helping Martin bring up the
> > new members.x.org so it's no longer an insanely insecure pile of PHP,
> > rewriting the fd.o homepage and lists of projects to not be massively
> > misleading, working on a lot on Wayland and Weston, working a bit on
> > Mesa/KMS/etc, then also doing my actual day job and taking care of my
> > personal life, I failed to make the time to specifically ensure that a
> > driver which has had one commit since 2010 was updated.
>
> It's just amazing how it is always the same repo and the same person
> that receives you and ajax special attention or more or less active lack
> thereof, depending on the situation.

You're right that it is a special case. We only have 5 repos which
have a bare directory name (without the '.git' suffix):
xf86-video-radeonhd, cairo-5c (Nickle), pycairo and py2cairo (dormant
since 2012), and roadster (dormant since 2009), compared to 1,268 with
the suffix. Of those, xf86-video-radeonhd is the only one which got
migrated to GitLab, which I migrated as soon as it was brought to my
attention, after manually renaming the repository since the migration
scripts break if the git.fd.o repo does not have the suffix.

I assume your next question is why it got quite uniquely created
without the suffix in the first place. For that, you'd have to ask the
person who created it:
drwxrwsr-x 8 eich xorg 4.0K Mar  7 21:31 xf86-video-radeonhd.git

As always, it's been an absolute pleasure helping you, and sitting in
my hotel room dealing with this has certainly been a much better use
of my holiday time than enjoying Tokyo.
___
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: Radeonhd repo not migrated to gitlab.

[Daniel Stone]

On Fri, 8 Mar 2019 at 09:52, Luc Verhaegen  wrote:
> On Fri, Mar 08, 2019 at 06:37:21AM +0900, Daniel Stone wrote:
> > FWIW, It was unique amongst all Xorg repos in that it didn't have a
> > .git suffix on the directory (i.e. its path was
> > /srv/git.freedesktop.org/git/xorg/driver/xf86-video-radeonhd/ rather
> > than .../xf86-video-radeonhd.git/), which might explain it if you were
> > pattern-matching to list all the repos. Certainly it broke the
> > migration script so I had to rename it by hand first. Anyway, it's
> > migrated now.
>
> And at no point in this process, or the past half a year or so, did you
> look at that actual list above and notice anything, right?
>
> *sigh*

I'll admit that somewhere between writing migration scripts, migrating
the other 1,268 repos from git.fd.o, maintaining our new and old
infrastructure, trying to find financial sponsorship for our
infrastructure, fire-fighting sudden 50% SMTP delivery failure rates,
bringing up a CI system and maintaining it as it exploded in use,
supporting people trying to use our new systems by walking them
through the API and bug-hunting for them, documenting and scripting
our new infrastructure so it can be replicated, dealing with regular
influxes of Bugzilla spam, trying to urgently move everyone off
Bugzilla as it's now abandoned upstream, helping Martin bring up the
new members.x.org so it's no longer an insanely insecure pile of PHP,
rewriting the fd.o homepage and lists of projects to not be massively
misleading, working on a lot on Wayland and Weston, working a bit on
Mesa/KMS/etc, then also doing my actual day job and taking care of my
personal life, I failed to make the time to specifically ensure that a
driver which has had one commit since 2010 was updated.
___
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: Radeonhd repo not migrated to gitlab.

[Daniel Stone]

On Fri, 8 Mar 2019 at 04:35, Adam Jackson  wrote:
> On Wed, 2019-03-06 at 17:04 +0100, Luc Verhaegen wrote:
> > Is there a reason why, of _all_ drivers listed in
> >
> > https://cgit.freedesktop.org/xorg/driver
> >
> > the Radeonhd repository at
> >
> > https://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/
> >
> > has not been mirrored?
>
> Pretty sure I came up with the list of modules to migrate from the set
> I happened to have cloned locally, but it's been months. I've added a
> note to the migration ticket:
>
> https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/40

... and I've migrated it.

FWIW, It was unique amongst all Xorg repos in that it didn't have a
.git suffix on the directory (i.e. its path was
/srv/git.freedesktop.org/git/xorg/driver/xf86-video-radeonhd/ rather
than .../xf86-video-radeonhd.git/), which might explain it if you were
pattern-matching to list all the repos. Certainly it broke the
migration script so I had to rename it by hand first. Anyway, it's
migrated now.

Cheers,
Daniel
___
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: Maintainer / Owner privileges at xf86-video-vmware

[Daniel Stone]

Hi Thomas,

On Fri, 22 Feb 2019 at 13:18, Thomas Hellstrom  wrote:
> I was trying to add Deepak Rawat as a member on the xf86-video-vmware
> project on fdo gitlab. Turns out I have only developer privileges
> there. Could someone please raise that to maintainer or owner?

Bouncing this over to xorg-devel; since moving to GitLab, the admins
are no longer involved in permission changes, but each project can do
that themselves.

Cheers,
Daniel
___
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: [Xcb] Migrating XCB to GitLab

[Daniel Stone]

Hi,

On Sat, 16 Feb 2019 at 18:21, Josh Triplett  wrote:
> On February 16, 2019 6:03:36 AM PST, Daniel Stone  
> wrote:
> >In doing the move, I think it makes sense to move the XCB modules in
> >under the xorg/ tree. I've suggested a module map here:
> >https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/40
>
> As a minor nit, "xcb-proto", rather than "xcbproto". Otherwise, your proposed 
> layout looks great to me. XCB is part of X, let's not keep it isolated.

Unfortunately I failed to read this before getting Uli's go-ahead on
IRC, so I did it with xcbproto. On the other hand, the other repos are
called e.g. 'xorgproto', 'dri3proto' etc rather than hyphenated, so
this fits in better.

I've done this now, including having moved the bugs over. \o/

Cheers,
Daniel
___
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

Migrating XCB to GitLab

[Daniel Stone]

Hi all,
As has been pretty well documented, I'd like to migrate XCB to GitLab
to join the rest of fd.o and X.Org (apart from the kernel and Mesa).

Whilst cgit/anongit would remain as mirrors, they would be read-only;
the sole push point would be GitLab. More details are here, but
essentially you can recover access to your account by just following
the 'forgot password' link and entering your mail:
https://gitlab.freedesktop.org/freedesktop/freedesktop/wikis/home

In doing the move, I think it makes sense to move the XCB modules in
under the xorg/ tree. I've suggested a module map here:
https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/40

Any thoughts? I'd like to get this over and done with quite soon.

Cheers,
Daniel
___
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: [RFC] Allow fd.o to join forces with X.Org

[Daniel Stone]

Hi,

On Fri, 26 Oct 2018 at 11:57, Daniel Vetter  wrote:
> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone  wrote:
> > > > Yeah, I think it makes sense. Some things we do:
> > > >   - provide hosted network services for collaborative development,
> > > > testing, and discussion, of open-source projects
> > > >   - administer, improve, and extend this suite of services as necessary
> > > >   - assist open-source projects in their use of these services
> > > >   - purchase, lease, or subscribe to, computing and networking
> > > > infrastructure allowing these services to be run
> > >
> > > I fully agree that we should document all this. I don't think the
> > > bylaws are the right place though, much better to put that into
> > > policies that the board approves and which can be adapted as needed.
> > > Imo bylaws should cover the high-level mission and procedural details,
> > > as our "constitution", with the really high acceptance criteria of
> > > 2/3rd of all members approving any changes. Some of the early
> > > discussions tried to spell out a lot of the fd.o policies in bylaw
> > > changes, but then we realized it's all there already. All the details
> > > are much better served in policies enacted by the board, like we do
> > > with everything else.
> > >
> > > As an example, let's look at XDC. Definitely one of the biggest things
> > > the foundation does, with handling finances, travel sponsoring grants,
> > > papers committee, and acquiring lots of sponsors. None of this is
> > > spelled out in the bylaws, it's all in policies that the board
> > > deliberates and approves. I think this same approach will also work
> > > well for fd.o.
> > >
> > > And if members are unhappy with what the board does, they can fix in
> > > the next election by throwing out the unwanted directors.
> >
> > yeah, fair call. though IMO in that case we can just reduce to
> >
> >\item Support free and open source projects through the freedesktop.org
> >infrastructure.
> >
> > because my gripe is less with the fdo bit but more with defining what
> > "project hosting" means, given that we use that term to exclude fdo projects
> > from getting anything else. I think just dropping that bit is sufficient.
>
> Hm yeah, through the lens of "everything not explicitly listed isn't in
> scope as X.org's purpose", leaving this out is probably clearest. And
> under 2.4 (i) the board already has the duty to interpret what exactly
> this means wrt membership eligibility.
>
> Harry, Daniel, what do you think?

Yeah, that's fine. I didn't specifically want the enumerated list of
what we do in the bylaws, just spelling it out for background as a
handy reference I could point to later. I think maybe we could reduce
it to something like:
  Administer, support, and improve the freedesktop.org hosting
infrastructure to support the projects it hosts

Gives us enough scope to grow in the future (e.g. we don't need a
bylaws change to move from pure-git to GitLab), avoids the sticky
question of what exactly fd.o hosts in the bylaws (e.g. if
NetworkManager needs a new repo then we don't have to consult
membership to add it), but is still pretty firmly limited in scope.

Any of the above have my in-principle ack though, I think they're all
reasonable colours for our lovely shed.

Cheers,
Daniel
___
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: [RFC] Allow fd.o to join forces with X.Org

[Daniel Stone]

On Tue, 16 Oct 2018 at 08:17, Peter Hutterer  wrote:
> On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > + \item Support free and open source projects through the 
> > freedesktop.org
> > + infrastructure. For projects outside the scope of item (\ref{1}) 
> > support
> > + extends to project hosting only.
> > +
>
> Yes to the idea but given that the remaining 11 pages cover all the legalese
> for xorg I think we need to add at least a section of what "project hosting"
> means. Even if it's just a "includes but is not limited to blah".  And some
> addition to 4.1 Powers is needed to spell out what the BoD can do in regards
> to fdo.

Yeah, I think it makes sense. Some things we do:
  - provide hosted network services for collaborative development,
testing, and discussion, of open-source projects
  - administer, improve, and extend this suite of services as necessary
  - assist open-source projects in their use of these services
  - purchase, lease, or subscribe to, computing and networking
infrastructure allowing these services to be run

Cheers,
Daniel
___
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: Smooth gdm -> GNOME3 session transition broken with 1.20 modesetting driver

[Daniel Stone]

Hi Hans,

On Wed, 5 Sep 2018 at 19:23, Hans de Goede  wrote:
> Under Fedora 29 (xserver-1.20) the transition from GDM to
> the GNOME3 session is no longer smooth, it seems that the
> screen is cleared to black when the Xserver starts instead
> of inheriting the framebuffer contents from GDM as before.
>
> Changing the DDX driver from modesetting to intel fixes this,
> I think this may be caused by the new atomic support in the
> modesetting driver.

It's caused by support for modifiers: this allows Mesa to use a
multi-planar framebuffer (auxiliary compression plane), which the new
X server can't then read back from because drmModeGetFB only supports
a single plane. I've written up the patches to do that[0], but last
time I tried to respin the current mainline was broken and didn't
actually boot. I've actually just picked that up this week and am
planning to send a new series out tomorrow.

[0]: https://lists.freedesktop.org/archives/xorg-devel/2018-March/056363.html

Cheers,
Daniel
___
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: [PATCH] xwayland: fix access to invalid pointer

[Daniel Stone]

Hi,

On Tue, 28 Aug 2018 at 21:30, Lionel Landwerlin
 wrote:
> xwl_output->randr_crtc is used in the update_screen_size() function :
>
> [...]
>
> @@ -392,14 +392,15 @@ xwl_output_remove(struct xwl_output *xwl_output)
>  int width = 0, height = 0;
>  Bool need_rotate = (xwl_output->xdg_output == NULL);
>
> -RRCrtcDestroy(xwl_output->randr_crtc);
> -RROutputDestroy(xwl_output->randr_output);
>  xorg_list_del(_output->link);
>
>  xorg_list_for_each_entry(it, _screen->output_list, link)
>  output_get_new_size(it, need_rotate, , );
>  update_screen_size(xwl_output, width, height);
>
> +RRCrtcDestroy(xwl_output->randr_crtc);
> +RROutputDestroy(xwl_output->randr_output);
> +
>  xwl_output_destroy(xwl_output);

I counter-suggested a patch on IRC, which keeps the RandR object
destroy lines where they are originally, and just tries to pick any
other output in the loop for output_get_new_size().

That makes the code even less obvious though, and the only benefit is if:
  - you have two outputs connected with the same pixel dimensions but
different physical dimensions
  - you disconnect one of them
  - you want newly-connected legacy clients to get the correct DPI
value through the connection handshake

I'm finding that usecase hard to care enough about that to justify how
ugly it is compared to this, so this patch is:
Reviewed-by: Daniel Stone 

Cheers,
Daniel
___
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: Window scaling (aka owner sizes)

[Daniel Stone]

On Mon, 27 Aug 2018 at 19:19, Keith Packard  wrote:
> Daniel Stone  writes:
> > It's the other way around. Wayland only has surface-relative
> > co-ordinates, so we take those and then translate them back into the
> > X11 global co-ordinate space.
>
> Oh, so if we know how XWayland is scaling the output to the screen, then
> we can translate the coordinates back to the correct root
> coordinates. That seems like it might be useful in supporting per-window
> scaling.

Yeah, it would be handy to support per-window scaling for high-DPI
environments with a mix of smart and dumb (wrt DPI) clients.

It's been easier for us to support scaling in Wayland since we have
fractional (±23.8) input co-ordinates. The window co-ordinate space is
always the same, which is emulating non-HiDPI: fullscreen on my
3200x1800 laptop is a 1600x900 surface space. If we have a client
which is aware of HiDPI and can render at full resolution, then it
attaches a full-size buffer and tells the compositor it's rendering at
native scale. But the input is handled as if it were 1600x900, and the
transfrom is effectively only during presentation to the output.

Cheers,
Daniel
___
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: Window scaling (aka owner sizes)

[Daniel Stone]

Hi,

On Mon, 27 Aug 2018 at 18:45, Keith Packard  wrote:
> Robert Mader  writes:
> > I can post my WIP work (will have to clean it up and rebase to current
> > master).
> > That said, I'm very interested to see this go forward and am very
> > willing to help :)
>
> I don't know how device coordinates are handled in XWayland, but this
> mechanism *might* help if you pass screen event coordinates down to X
> for it to then convert into window coordinates?

It's the other way around. Wayland only has surface-relative
co-ordinates, so we take those and then translate them back into the
X11 global co-ordinate space.

Cheers,
Daniel
___
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: [ANN] edid-decode maintenance info

[Daniel Stone]

Hi,

On Sun, 12 Aug 2018 at 21:53, Alan Coopersmith
 wrote:
> On 06/22/18 01:12 AM, Hans Verkuil wrote:
> > Thank you for this information. I looked through all the bug reports and
> > 100607, 100340 and 93366 were already fixed before I took over maintenance.
> >
> > I just fixed 89348 and 93777 in my git repo, so those can be marked as
> > resolved.
>
> Since no one else has, I marked all of these resolved now with links to your
> repo for the fixes.
>
> > The edid-decode component should probably be removed from the freedesktop
> > bugzilla.
>
> I don't know how to do that without deleting the bugs, so I'm hoping Adam
> or Daniel can do that, much as they've been doing for the stuff migrating
> to gitlab.

edid-decode is already marked as inactive; the old bugs aren't deleted
and it's possible to search by component, but you can't file new bugs
against it.

Cheers,
Daniel
___
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: gitlab migration (including account update plans, please read)

[Daniel Stone]

Hi Alan,

On Sun, 29 Jul 2018 at 16:53, Alan Coopersmith
 wrote:
> On 07/29/18 03:07 AM, Daniel Stone wrote:
> > This took a little longer than hoped, but all the repos have now been moved.
>
> Huge thanks for doing this.
>
> I updated all my local clones with:
>
> git remote set-url origin `git remote get-url origin | sed \
>'s%ssh://git.freedesktop.org/git/%ssh://g...@gitlab.freedesktop.org/%'`
>
> but got errors that gitlab couldn't find app/bdftopcf, app/rendercheck,
> and app/x11perf.
>
> Did something go wrong with them?   I don't see them in the web ui at
> https://gitlab.freedesktop.org/xorg/app either.

Not wrong as such, just moved. These are the modules which (as
requested) changed relative path during the migration:
xorg/app/bdftopcf -> xorg/util/bdftopcf
xorg/app/rendercheck -> xorg/test/rendercheck
xorg/app/x11perf -> xorg/test/x11perf
xorg/app/xtsttopng -> xorg/test/xtsttopng
xorg/driver/glamor -> xorg/driver/glamor-history
xorg/xprint -> xorg/xserver-xprint
avivo/xf86-video-avivo -> xorg/driver/xf86-video-avivo
glitz -> xorg/driver/glitz-history

If you try to fetch from the old URL it will still work, and if you
try to push to the old URL it will tell you the correct new URL to
use.

> I also got the same error from xf86-video-nouveau, xf86-video-openchrome,
> libvdpau, and xcb/* but I'm assuming that was my script going too far and
> those projects not migrating yet.

Right, exactly. Nothing under a non-xorg/ path has yet moved.

Cheers,
Daniel
___
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: gitlab migration (including account update plans, please read)

[Daniel Stone]

Hi,

On Mon, 23 Jul 2018 at 16:24, Adam Jackson  wrote:
> My earlier assertion about the git url not being changed is only true
> for pulls. For pushes, you will indeed need to update the remote to the
> new URL:
>
> $ git remote set-url origin ssh://g...@gitlab.freedesktop.org/xorg/xserver
>
> Repo moves will be (early) this week. BZ moves for the more boring
> components (protocol, libs, apps, deprecated/abandoned stuff) will
> follow shortly thereafter.

This took a little longer than hoped, but all the repos have now been moved.

Cheers,
Daniel
___
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: [PATCH xserver] xf86-video-modesetting: Lease planes as well if using atomic

[Daniel Stone]

Hi,

On Wed, 27 Jun 2018 at 00:35, Keith Packard  wrote:
> @@ -3251,6 +3251,9 @@ drmmode_create_lease(RRLeasePtr lease, int *fd)
>
>  nobjects = ncrtc + noutput;
>
> +if (ms->atomic_modeset)
> +nobjects += ncrtc;

This seems like it definitely wants a comment as 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/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] xf86-video-modesetting: Don't enable UNIVERSAL_PLANES separately

[Daniel Stone]

On Tue, 26 Jun 2018 at 22:06, Keith Packard  wrote:
> We don't want universal_planes unless we're using atomic APIs for
> modesetting, and the kernel already enables universal_planes
> automatically when atomic is enabled.
>
> If we enable universal_planes when we're not using 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
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver v2 1/2] glamor: Unbreak glamor_fd_from_pixmap()

[Daniel Stone]

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, pixmap, , , NULL, size,
> +  NULL);
> +if (ret != 1)
>  return -1;

This needs the removed code just above it, where it closes excess FDs.
I think the rest looks good though; I don't have a PRIME system so
wasn't able to test at the time.

Cheers,
Daniel
___
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: gitlab migration

[Daniel Stone]

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).
>
> >> Strongly agree, especially for returning useful search results!!!
>
> > What kind of searches have you tried which returned better search
> > results on Bugzilla than GitLab?
>
> I gave up trying too long ago to remember. Best of my recollection is all of
> them, generally getting too many to sift through, or zarro. I'm speaking of
> gitlab/github (which is it anyway?) generally, not any specific project's. BZ 
> I
> got used to over 17 years go, when learning new things had not yet become
> problematic.

GitLab and GitHub are two completely different services. They offer
different features in different ways through different user
interfaces, and have both been evolving pretty quickly. Saying
emphatically!!! that GitLab's search results are useless, based on
vague recollections of having used a _different service_ which was so
long ago you can't even remember, isn't really a great contribution to
a discussion.

> Bad as yesteryear's web was, the current one is worse. Firefox ESR 60 download
> is 648% the size of Firefox 1.0. All the benefit of broadband has been eaten 
> up
> by bottlenecks, bloated browsers and gargantuan web pages. Googling 'gitlab
> xorg' or 'github xorg' don't provide anything resembling an actual home page 
> URI
> like https://bugs.freedesktop.org/. https://www.x.org/wiki/Development/ 
> doesn't
> either. Maybe these are a good sign, one to indicate Ajax's migration hasn't
> actually started.

Yes. This thread is to discuss migrating to GitLab at some point in
the future. Since it has not happened yet, there is no entrypoint to
speak of.

I can't solve your problems with web browsers, bottlenecks and people
using JavaScript, but again, both Bugzilla and GitLab are web-based
tools, and GitLab has a complete API with CLI-based tools you can use
instead of a browser.

Cheers,
Daniel
___
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: gitlab migration

[Daniel Stone]

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 returned better search
results on Bugzilla than GitLab?

Cheers,
Daniel
___
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: gitlab migration

[Daniel Stone]

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 and malicious and should never be
> used by any site, under any circumstances.
>
> If some sort of captcha is ever desired, it always must be something
> which works with non-ecmacsipt, TUI browsers.
>
> A simple math question with a simple html text box for the answer is OK.
> Or a technical question specific to the given project.
>
> But never goog's malicious crap.

I assume that you're unaware of the levels of spam we've been dealing
with, including the number of times we've been blacklisted by major
mail providers, the extent to which search engines used to distrust
us, and the amount of admin time spent dealing with it.

Now you've got whatever it was out of your system, maybe you could
come back with some kind of actionable feedback, or a constructive
plan to address the genuine problems that we've been discussing both
here and at various conferences for the last two or three years which
have led to GitLab. Maybe you could venture a real suggestion for
dealing with spam which also works with noscript lynx or whatever;
ideally one which was better than our previous version which did
genuinely cause people issues. Or maybe you could go look at the CLI
client for GitLab I've already pointed to, and read the API
documentation. Or just continue the useless flames trying to enforce
your opinion as universal fact, every single line of which should
carry '[citation needed]'.
___
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: gitlab migration

[Daniel Stone]

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
>> > empty "white list" in firefox or chromium, or use lynx or links or w3m).
>>
>> No need to test; it's guaranteed to fail since we require Recaptcha
>> for login due to massive spam issues.
>
> Have you tested whether Chinese or Russian users can login or sign up?
> Asking because Recaptcha was blocked for quite a long time by Russian
> authorities.

We do have active users from both countries currently.

Cheers,
Daniel
___
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: gitlab migration

[Daniel Stone]

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': https://gitlab.com/zaquestion/lab which provide a good CLI
>> interface.
>
> Those "web APIs" usually require the use of an heavy javascript browser for
> authentification or "app authorization".
>
> 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
> empty "white list" in firefox or chromium, or use lynx or links or w3m).

No need to test; it's guaranteed to fail since we require Recaptcha
for login due to massive spam issues.

Cheers,
Daniel
___
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: gitlab migration

[Daniel Stone]

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 migration provides
>> some useful background:
>>
>> https://lists.x.org/archives/mesa-dev/2018-May/195634.html
>>
>> This should be mostly mechanical, except for moving some of the older
>> junk into the archive and deciding which drivers _not_ to move yet (I
>> imagine intel has some of its processes hooked up to bz, for example).
>
> As the maintainer of xf86-video-amdgpu and -ati, I'm fine with migrating
> these to GitLab for Git and patch review.
>
> However, I'm not sure what to do about bugs/issues. My first thought was
> to allow creating new issues in GitLab and disable creating new reports
> in Bugzilla, but not to migrate existing reports from Bugzilla. However,
> it still happens fairly often that a report is initially filed against
> the Xorg drivers, even though it's actually an issue in the X server,
> Mesa or the kernel (old habits die hard...). Therefore, I'm inclined to
> stick to Bugzilla until at least the X server and Mesa have moved to
> GitLab for issue tracking, to hopefully allow moving such misfiled issues.

One thing some Mesa people said during that discussion is that they
like the ability to move issues between Mesa and the kernel, which
won't be possible if they're on split systems. So I probably wouldn't
hold my breath for that to be honest.

Cheers,
Daniel
___
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: gitlab migration

[Daniel Stone]

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 attempted a migration on gitlab of my repos but I was blocked because it's
> not noscript/xhtml basic browser friendly.
>
> I was successfull with launchpad.net (which has now git support).
>
> I did not test if the issue system was noscript/xhtml basic friendly though.

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': https://gitlab.com/zaquestion/lab which provide a good CLI
interface.

Cheers,
Daniel
___
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: gitlab migration

[Daniel Stone]

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 background:
>>
>> https://lists.x.org/archives/mesa-dev/2018-May/195634.html
>>
>> This should be mostly mechanical, except for moving some of the older
>> junk into the archive and deciding which drivers _not_ to move yet (I
>> imagine intel has some of its processes hooked up to bz, for example).

Migrating bugs is pretty easy, but there are currently over 2800 bugs
in the 'xorg' product, of which 921 are in the server +
xf86-video-modesetting + xf86-input-{evdev,libinput} components. The
import does preserve components as tags, and it does add a 'bugzilla'
tag to make it fairly easy to see what has and hasn't been triaged,
but I would seriously recommend doing a massive clean-up pass before
doing the migration. Easier said than done, of course.

>> As far as contribution model, I'd personally prefer to stop using
>> mailing lists, and for most of the X components I expect that's
>> probably an improvement, because most components do not have especially
>> active maintenance and it's currently very easy for patches to get lost
>> in the mailing list history. Conversely for the server it can be
>> difficult to keep track of a patch series' approval state. Again, not
>> solely my decision to make, so I'd like to hear some rough consensus on
>> how to proceed. Anyone with strong opinions, please do speak up.
>
> I, for one, would love to see xserver use a MR-based contribution
> process.  Every once in a while I go to review some old patches I had
> personally marked as still to be reviewed, and find they're already
> merged.  I'm sure the reverse is happening, too.
>
> For our libraries with less active maintainership, MRs that stay open
> until they're actually handled should be an even bigger win.
>
> I'm also *really* interested in a merge process that runs through the
> server's automated tests before the code hits master.  I know that won't
> be day 1, but gitlab is progress toward that.

Totally AOL from me. It looks like the repo currently runs exactly the
same tests on GitLab CI as it did through Travis, for Linux at least.
For Windows we can set up a GitLab -> Appveyor hook to check and just
reuse that directly. That leaves us with OS X: we don't have an OS X
CI worker set up for fd.o, and Travis have flatly said they don't plan
to build any integration with GitLab. GStreamer do have OS X workers
for Jenkins, and they're actively looking into migrating to GitLab; I
believe their OS X worker more or less works. Maybe once they've moved
we could reuse that and cover all three platforms that way.

I'd be interested to see the relative speed of our worker compared to
Travis. If it is a bit slower, then we're actively working on sourcing
more CI workers, both x86 and ARM; hopefully within the month or so.
If it's already faster, great.

Cheers,
Daniel
___
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: [PATCH xserver] glamor: Enable modifier support for xfree86 too

[Daniel Stone]

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
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xkbcomp] Ignore xkb_keycodes.maximum of > 255

[Daniel Stone]

On 7 June 2018 at 05:13, Peter Hutterer  wrote:
> Continuation from 7fdfabd75 "keycodes: Ignore high keycodes"
>
> A keymap with a key > 255 will have a xkb_keycodes.maximum of that keycode.
> Let's not throw a fatal error on that, just crop it back to the maximum of
> 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
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Obtaining Xorg DDX commit privilege

[Daniel Stone]

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 proxy to the
actual project owners. The reason your bug hasn't been acted on is
that it needs to have someone from X.Org say 'yes, this is fine and
Kevin should have commit access to all our repositories'.

Often the process is to start sending out patches, e.g. to fix these
compilation warnings for the other DDXes, and after a few have been
merged and both sides have built up some confidence then you apply for
direct commit access.

Cheers,
Daniel
___
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: Stepping back

[Daniel Stone]

Hi,

On 15 May 2018 at 06:43, Alan Coopersmith  wrote:
> On 05/14/18 12:58 PM, Keith Packard wrote:
>> Adam Jackson  writes:
>>> tl;dr: I will not be release manager for 1.21, nor for anything
>>> thereafter either, and this time that's probably permanent.
>>
>> I'd like to thank you for all of the work you have done and with you all
>> the best in your next adventures.
>
> +1

+lots

Really appreciate the effort you made to herd everything into place
and go well out of your way to land everything.

>>> As for what this means for tree management and future release plans,
>>> well, I can't answer that, that's sort of the point. There's a
>>> community discussion that needs to happen there, and my opinions can't
>>> dominate that if I'm serious about stepping back.
>>
>> We can start discussions now, and I think we should plan on holding a
>> discussion about this during XDC in September.
>
> While in person discussions can be efficient, I do wonder if limiting
> them to people who can travel to XDC is how we end up burning out the
> same folks over and over.
>
> I don't have great answers as more of us step back like I did a few
> years back and Adam is doing now, but with few new folks coming into
> our maintainer fold in the past decade, we need to figure out how to
> both get more contributors and how to grow them into maintainers.

We've been facing the same question in Wayland. Here's what I wrote up
about what I think we should do with that:
  https://lists.freedesktop.org/archives/wayland-devel/2018-May/038100.html

Personally I think having longer discussions and write-ups in
bugs/issues would make the development a lot more accessible. The list
is great and it does serve its purpose, but it throws up a barrier to
entry: you have to be subscribed to the list and get all the mail, to
participate in discussion. (And that's before you get to the barrier
to entry of git-send-email etc.)

I don't really have enough of a stake to make suggestions for X
development, but that might at least be a good starting point for
spreading the load a bit.

> While Wayland is certainly making great strides, I don't think the world
> is yet ready to stop using X altogether, but it's getting harder and
> harder for us to keep X alive.

Ah yes, the year of Wayland on the desktop. ;)

Cheers,
Daniel
___
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: [PATCH 2/2] loader_dri3: Variant 2: Wait for pending swaps to complete before drawable_fini.

[Daniel Stone]

On 5 May 2018 at 10:15, Mike Lothian  wrote:
> Out of interest can you try running the vulkan smoketest, I'm seeing this:
>
> smoketest
> terminate called after throwing an instance of 'std::runtime_error'
>  what():  VkResult -101004 returned
> Aborted (core dumped)

VK_ERROR_OUT_OF_DATE_KHR is returned from vkQueuePresentKHR when the
application _must_ recreate the swapchain it uses for rendering.
Usually this happens due to the window resizing (which the window
manager can do), which Vulkan apps _must_ handle themselves. The
smoketest chooses to handle this error by crashing.
___
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: [PATCH xserver] modesetting: Remove ms_crtc_msc_to_kernel_msc().

[Daniel Stone]

Hi Mario,

On 4 May 2018 at 13:14, Mario Kleiner  wrote:
> Indeed, i found a Mesa bug yesterday which can cause Mesa's
> PresentPixmap request to spuriously feed garbage targetMSC's
> into the driver under some conditions. However, while other
> video drivers seem to cope relatively well with that, modesetting
> ddx causes KDE-5's plasmashell to lock up badly quite frequently,
> and my suspicion is that the code removed in this commit is one
> major source of the extra fragility.

Thanks a lot for tracking this down! Adding Eero to Cc, who I think
stumbled on this very problem.

Cheers,
Daniel
___
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: [PATCH xserver] xwayland: Avoid using epoxy_has_egl()

[Daniel Stone]

On 30 April 2018 at 19:10, Adam Jackson <a...@redhat.com> wrote:
> There's no real point - if we don't have EGL then the extension check is
> also going to fail - and the entrypoint is new in 1.5.0, which we don't
> need to require yet.

Reviewed-by: Daniel Stone <dani...@collabora.com>
___
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 xserver] dri3: Don't call vfuncs on old DRI3 screens

[Daniel Stone]

Only call the get_supported_modifiers vfunc if the DRI3 screen struct is
sufficiently new.

Signed-off-by: Daniel Stone <dani...@collabora.com>
---
 dri3/dri3_screen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
index 23e33f401..a1d6f47dd 100644
--- a/dri3/dri3_screen.c
+++ b/dri3/dri3_screen.c
@@ -171,7 +171,7 @@ cache_formats_and_modifiers(ScreenPtr screen)
 if (!info)
 return BadImplementation;
 
-if (!info->get_formats || !info->get_modifiers) {
+if (info->version < 2 || !info->get_formats || !info->get_modifiers) {
 ds->formats = NULL;
 ds->num_formats = 0;
 ds->formats_cached = TRUE;
-- 
2.17.0

___
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: [PATCH xserver] dri3: Clamp to 1.0 if not all screens support 1.2

[Daniel Stone]

Hi Adam,

On 24 April 2018 at 21:08, Adam Jackson <a...@redhat.com> wrote:
> +for (int i = 0; i < screenInfo.numScreens; i++) {
> +if (!dri3_screen_can_one_point_two(screenInfo.screens[i])) {
> +rep.minorVersion = 0;
> +break;
> +}
> +}
> +
> +for (int i = 0; i < screenInfo.numGPUScreens; i++) {
> +if (!dri3_screen_can_one_point_two(screenInfo.gpuscreens[i])) {
> +rep.minorVersion = 0;
> +break;
> +}
> +}

Makes sense, but would this disable v1.2 for, e.g., UDL?

I've sent another one I just spotted by inspection, but this is:
Reviewed-by: Daniel Stone <dani...@collabora.com>

Cheers,
Daniel
___
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: [PATCH xserver] dri3: Fix DRI3.2 support for drivers other than modesetting-ddx.

[Daniel Stone]

Hi Adam,

On 24 April 2018 at 20:52, Adam Jackson <a...@nwnk.net> wrote:
> On Tue, 2018-04-24 at 11:42 +0100, Daniel Stone wrote:
>> On 24 April 2018 at 09:17, Mario Kleiner <mario.kleiner...@gmail.com> wrote:
>> > Both xf86-video-intel and xf86-video-nouveau cause OpenGL
>> > clients to fail when used with DRI3 on server 1.20 with Mesa 18.1.
>> >
>> > Reason is that the servers DRI3 version is now unconditionally
>> > reported as DRI3 1.2 to 1.2 capable clients. This causes clients
>> > using Mesa 18.1 to use the new DRI 3.2 requests DRI3GetSupportedModifiers,
>> > DRI3PixmapFromBuffers, etc. Drivers other than modesetting-ddx
>> > do not support the needed hooks like info->pixmap_from_fds or
>> > info->get_formats, info->get_modifiers. Unfortunately we can't
>> > simply report the servers DRI3 version as 1.0 in this case, as
>> > the reported version can not be specific to a X-Screen, and
>> > different screens may have drivers with different capabilities.
>
> I think this implies we should not advertise 1.2 if any screen lacks
> the 1.2 hooks.

To be honest, I'd be fine with that too.

>> Thanks a lot for hunting this down! This fix does still make me
>> uncomfortable though. I think a better fix would be, on the Mesa side,
>> to never call any 1.2 codepaths for the server if we get no
>> formats/modifiers back from the GetSupported calls, and to never call
>> any 1.2 codepaths for the drawable if DRIImage's
>> createImageWithModifiers does not exist or if it fails and we fall
>> back to regular createImage. That way we make sure that both sides
>> exercise the same behaviour: either both with explicit modifiers, or
>> neither.
>
> The problem with that strategy is it means 1.20 would be compatible
> with zero already-released versions of Mesa.

True, though it is only 18.1.0rc1 broken now, and we've plenty of time
before rc2.

Cheers,
Daniel
___
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: [PATCH xserver] dri3: Fix DRI3.2 support for drivers other than modesetting-ddx.

[Daniel Stone]

Hi Mario,

On 24 April 2018 at 09:17, Mario Kleiner  wrote:
> Both xf86-video-intel and xf86-video-nouveau cause OpenGL
> clients to fail when used with DRI3 on server 1.20 with Mesa 18.1.
>
> Reason is that the servers DRI3 version is now unconditionally
> reported as DRI3 1.2 to 1.2 capable clients. This causes clients
> using Mesa 18.1 to use the new DRI 3.2 requests DRI3GetSupportedModifiers,
> DRI3PixmapFromBuffers, etc. Drivers other than modesetting-ddx
> do not support the needed hooks like info->pixmap_from_fds or
> info->get_formats, info->get_modifiers. Unfortunately we can't
> simply report the servers DRI3 version as 1.0 in this case, as
> the reported version can not be specific to a X-Screen, and
> different screens may have drivers with different capabilities.

Thanks a lot for hunting this down! This fix does still make me
uncomfortable though. I think a better fix would be, on the Mesa side,
to never call any 1.2 codepaths for the server if we get no
formats/modifiers back from the GetSupported calls, and to never call
any 1.2 codepaths for the drawable if DRIImage's
createImageWithModifiers does not exist or if it fails and we fall
back to regular createImage. That way we make sure that both sides
exercise the same behaviour: either both with explicit modifiers, or
neither.

Cheers,
Daniel
___
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: [PATCH xserver 3/3] xwayland: Add glamor egl_backend for EGLStreams

[Daniel Stone]

Hi,

On 20 April 2018 at 19:38, Adam Jackson <a...@redhat.com> wrote:
> This adds initial support for displaying Xwayland applications through
> the use of EGLStreams and nvidia's custom wayland protocol by adding
> another egl_backend driver. This also adds some additional egl_backend
> hooks that are required to make things work properly.
>
> EGLStreams work a lot differently then the traditional way of handling
> buffers with wayland. Unfortunately, there are also a LOT of various
> pitfalls baked into it's design that need to be explained.

This is every bit as unpleasant as the commit message details, but I'm
not sure how you'd do it better, and it is at least minimally
intrusive to the rest.

Acked-by: Daniel Stone <dani...@collabora.com>

Cheers,
Daniel
___
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: [PATCH xserver 2/3] xwayland: Add xwayland-config.h

[Daniel Stone]

On 20 April 2018 at 19:38, Adam Jackson <a...@redhat.com> wrote:
> Just a small autogenerated header that will soon contain more then just
> one macro.
>
> Signed-off-by: Lyude Paul <ly...@redhat.com>

Reviewed-by: Daniel Stone <dani...@collabora.com>
___
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: [PATCH xserver 1/3] xwayland: Decouple GBM from glamor

[Daniel Stone]

Hi,

On 20 April 2018 at 19:38, Adam Jackson <a...@redhat.com> wrote:
> This takes all of the gbm related code in wayland-glamor.c and moves it
> into it's own EGL backend for Xwayland, xwayland-glamor-gbm.c.
> Additionally, we add the egl_backend struct into xwl_screen in order to
> provide hooks for alternative EGL backends such as nvidia's EGLStreams.

I do think the end result of this commit is better; there are a lot of
good cleanups in here. It would be much easier to review next time
though, if this was broken into a few separate commits. There is mass
code motion, resequencing of functions, reordering of struct members,
minor changes of struct declarations (e.g. void * -> EGLImage in
xwl_pixmap), a lot of formatting changes, and other cleanups like
moving variable declarations into child blocks. It's taken until now
to review it because I've got four panes open with new and old code
side by side, with quite a lot of back and forth.

> +_X_EXPORT Bool
> +glamor_get_formats(ScreenPtr screen,
> +   CARD32 *num_formats, CARD32 **formats)
> +{
> +struct xwl_screen *xwl_screen = xwl_screen_get(screen);
> +struct xwl_gbm_private *xwl_gbm = xwl_gbm_get(xwl_screen);
> +int i;
> +
> +if (!xwl_gbm->dmabuf_capable || !xwl_gbm->dmabuf)
> +return FALSE;
> +
> +if (xwl_screen->num_formats == 0) {
> +   *num_formats = 0;
> +   return TRUE;
> +}

Changes from ac48724639e0a6a9e421b3b4e545d8506fd6bf5dost in rebase.

> +_X_EXPORT Bool
> +glamor_get_modifiers(ScreenPtr screen, CARD32 format,
> + CARD32 *num_modifiers, uint64_t **modifiers)
> +{
> +struct xwl_screen *xwl_screen = xwl_screen_get(screen);
> +struct xwl_gbm_private *xwl_gbm = xwl_gbm_get(xwl_screen);
> +struct xwl_format *xwl_format = NULL;
> +int i;
> +
> +if (!xwl_gbm->dmabuf_capable || !xwl_gbm->dmabuf)
> +return FALSE;
> +
> +/* Explicitly zero the count as the caller may ignore the return value */
> +*num_modifiers = 0;

Changes from b36a14c0b0e7e38406622eb5ff0666a8b8bc50f4 misplaced in rebase.

> +static void
> +xwl_drm_handle_device(void *data, struct wl_drm *drm, const char *device)
> +{
> +   struct xwl_screen *xwl_screen = data;
> +   struct xwl_gbm_private *xwl_gbm = xwl_gbm_get(xwl_screen);
> +   drm_magic_t magic;
> +
> +   xwl_gbm->device_name = strdup(device);
> +   if (!xwl_gbm->device_name) {
> +   xwl_glamor_gbm_cleanup(xwl_screen);
> +   return;
> +   }
> +
> +   xwl_gbm->drm_fd = open(xwl_gbm->device_name, O_RDWR | O_CLOEXEC);
> +   if (xwl_gbm->drm_fd == -1) {
> +   ErrorF("wayland-egl: could not open %s (%s)\n",
> +  xwl_gbm->device_name, strerror(errno));
> +   xwl_glamor_gbm_cleanup(xwl_screen);
> +   return;
> +   }
> +
> +   if (is_fd_render_node(xwl_gbm->drm_fd)) {
> +   xwl_gbm->fd_render_node = 1;
> +   xwl_screen->expecting_event--;
> +   } else {
> +   drmGetMagic(xwl_gbm->drm_fd, );
> +   wl_drm_authenticate(xwl_gbm->drm, magic);
> +   }
> +}

e.g. here, the change to expecting_event is unnecessary; the previous
code explicitly decremented and re-incremented to make it clear which
event was which, and the change meant I had to double back and read
through the whole init flow again. The current code is still correct,
and I don't care enough to ask for it to be made back the way it was,
but in future please try to keep these kinds of subtle changes
separate from mass code motion.

The rest is:
Reviewed-by: Daniel Stone <dani...@collabora.com>

Cheers,
Daniel
___
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: [PATCH xserver v2] xwayland: avoid using freed xwl_window on unrealize

[Daniel Stone]

Hi,

On 19 April 2018 at 16:05, Olivier Fourdan  wrote:
> (gdb) f 9
> #9  xwl_present_frame_callback (data=0x184cb10, callback=,
> time=) at xwayland-present.c:192
> 192wl_callback_destroy(xwl_window->present_frame_callback);
> (gdb) list
> 187   struct wl_callback *callback,
> 188   uint32_t time)
> 189{
> 190struct xwl_window *xwl_window = data;
> 191
> 192wl_callback_destroy(xwl_window->present_frame_callback);
> 193xwl_window->present_frame_callback = NULL;
> 194
> 195if (xwl_window->present_timer_firing) {
> 196/* If the timer is firing, this frame callback is too late */
>
> Looks like we're not done yet :/
>
> I'll try that other patch I sent and see if that makes a difference here,
> could be related according to the backtrace I guess...

The callback is passed as an argument to the function directly, so you
could just destroy that instead.

Cheers,
Daniel
___
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: [PATCH xserver 15/15] dri3: correctly handle failed get_supported_modifiers requests

[Daniel Stone]

Hi,

On 6 April 2018 at 12:18, Emil Velikov  wrote:
> On 4 April 2018 at 19:51, Adam Jackson  wrote:
>> This, combined with 10/15, means you will now throw BadImplementation
>> when we used to succeed and simply report no modifiers. I can't think
>> of a good reason to make that an error, it just makes the client's life
>> harder if it has to distinguish error from reply.
>
> I'm a bit split - on one hand any reasonable client should do error checking.
> At least the Mesa one seems to do so.
>
> On the other, the client would handle failed and 0 modifiers identically.

We generally reserve protocol errors for 'client screwed up' (most
errors), or 'server has tied itself into a knot and does not know how
to escape' (BadImplementation). The latter is usually accompanied by a
comment saying '/* XXX: This is really hard so I didn't */'. In both
cases, there's no way to do what the client wants so we send an error
down to let it know that its expectations have been broken and it's
difficult to recover.

On the other hand, zero is a completely valid answer to 'how many
modifiers do you support?', so that's what we should return. Error
handling from asynchronous protocols is far more difficult than from
just making a C function call, hence why we reserve it for cases which
require active recovery, or are unrecoverable.

Cheers,
Daniel
___
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: [PATCH xserver] modesetting: Fix page flipping under DRI 3.2.

[Daniel Stone]

Hi,

On 6 April 2018 at 09:48, Mike Lothian  wrote:
> Thanks for reminding me about GLX vs EGL
>
> The config option in KDE was removed from the System Setting app and can
> only be adjusted manually in in ~/.config/kwinrc
>
> GLPlatformInterface=egl
>
> This might explain why Daniel hasn't been seeing the issues I've been seeing

I tried this on both i915 (Skylake) and amdgpu, both of which work fine. :(

KWin does seem to be extremely verbose: can you please capture the
console output from it?

Cheers,
Daniel
___
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 xserver v3 3/3] modesetting: Actually get framebuffer ID

[Daniel Stone]

We would fail to get the FB ID if it wasn't already imported, since we
were checking to see if the pointer was NULL (it never was) rather than
if the content of the pointer was 0.

Signed-off-by: Daniel Stone <dani...@collabora.com>
Reported-by: Olivier Fourdan <ofour...@redhat.com>
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index cdcd4f3f3..322ef050b 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -624,7 +624,7 @@ drmmode_crtc_get_fb_id(xf86CrtcPtr crtc, uint32_t *fb_id, 
int *x, int *y)
 *y = crtc->y;
 }
 
-if (fb_id == 0) {
+if (*fb_id == 0) {
 ret = drmmode_bo_import(drmmode, >front_bo,
 >fb_id);
 if (ret < 0) {
-- 
2.16.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

[PATCH xserver v3 1/3] modesetting: Don't reuse iterator in nested loop

[Daniel Stone]

drmmode_crtc_set_mode has a loop nested inside another loop, where both
of them were using 'i' as the loop iterator. Rename it to avoid an
infinite loop.

Signed-off-by: Daniel Stone <dani...@collabora.com>
Reported-by: Michel Dänzer <michel.daen...@amd.com>
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
Tested-by: Michel Dänzer <michel.daen...@amd.com>
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 2b04c3555..cdcd4f3f3 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -777,12 +777,13 @@ drmmode_crtc_set_mode(xf86CrtcPtr crtc, Bool test_only)
 drmmode_crtc_private_ptr other_drmmode_crtc = 
other_crtc->driver_private;
 int lost_outputs = 0;
 int remaining_outputs = 0;
+int j;
 
 if (other_crtc == crtc)
 continue;
 
-for (i = 0; i < xf86_config->num_output; i++) {
-xf86OutputPtr output = xf86_config->output[i];
+for (j = 0; j < xf86_config->num_output; j++) {
+xf86OutputPtr output = xf86_config->output[j];
 drmmode_output_private_ptr drmmode_output = 
output->driver_private;
 
 if (drmmode_output->current_crtc == other_crtc) {
-- 
2.16.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

[PATCH xserver v3 2/3] dri3: Set stride and size for old clients

[Daniel Stone]

For old clients using the fd_from_pixmap entrypoint, make sure we set
stride and size correctly.

Noticed by inspection.

Signed-off-by: Daniel Stone <dani...@collabora.com>
---
 dri3/dri3_screen.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
index 41595f412..8ccbeb40c 100644
--- a/dri3/dri3_screen.c
+++ b/dri3/dri3_screen.c
@@ -161,6 +161,8 @@ dri3_fd_from_pixmap(PixmapPtr pixmap, CARD16 *stride, 
CARD32 *size)
 return -1;
 }
 
+*stride = strides[0];
+*size = size[0];
 return fds[0];
 }
 
-- 
2.16.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

Re: [PATCH xserver 1/2] modesetting: Don't reuse iterator in nested loop

[Daniel Stone]

On 5 April 2018 at 15:06, Walter Harms <wha...@bfs.de> wrote:
>> Daniel Stone <dani...@collabora.com> hat am 5. April 2018 um 15:58
>> geschrieben:
>> -for (i = 0; i < xf86_config->num_output; i++) {
>> -xf86OutputPtr output = xf86_config->output[i];
>> +for (j = 0; i < xf86_config->num_output; j++) {
>> +xf86OutputPtr output = xf86_config->output[j];
>
> Your intention is to loop over J but terminate with i ?
> that is at least confusing.

Today really isn't my day. Apologies.
___
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 xserver v2 2/2] dri3: Set stride and size for old clients

[Daniel Stone]

For old clients using the fd_from_pixmap entrypoint, make sure we set
stride and size correctly.

Noticed by inspection.

Signed-off-by: Daniel Stone <dani...@collabora.com>
---
 dri3/dri3_screen.c | 2 ++
 1 file changed, 2 insertions(+)

Sorry, accidentally sent the previous without having committed the fix.

diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
index 41595f412..8ccbeb40c 100644
--- a/dri3/dri3_screen.c
+++ b/dri3/dri3_screen.c
@@ -161,6 +161,8 @@ dri3_fd_from_pixmap(PixmapPtr pixmap, CARD16 *stride, 
CARD32 *size)
 return -1;
 }
 
+*stride = strides[0];
+*size = size[0];
 return fds[0];
 }
 
-- 
2.17.0

___
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 xserver 2/2] dri3: Set stride and size for old clients

[Daniel Stone]

For old clients using the fd_from_pixmap entrypoint, make sure we set
stride and size correctly.

Noticed by inspection.

Signed-off-by: Daniel Stone <dani...@collabora.com>
---
 dri3/dri3_screen.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
index 41595f412..a111ee50f 100644
--- a/dri3/dri3_screen.c
+++ b/dri3/dri3_screen.c
@@ -161,6 +161,8 @@ dri3_fd_from_pixmap(PixmapPtr pixmap, CARD16 *stride, 
CARD32 *size)
 return -1;
 }
 
+*stride = strides[0];
+*size = sizes[0];
 return fds[0];
 }
 
-- 
2.17.0

___
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 xserver 1/2] modesetting: Don't reuse iterator in nested loop

[Daniel Stone]

drmmode_crtc_set_mode has a loop nested inside another loop, where both
of them were using 'i' as the loop iterator. Rename it to avoid an
infinite loop.

Signed-off-by: Daniel Stone <dani...@collabora.com>
Reported-by: Michel Dänzer <michel.daen...@amd.com>
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 0eacefba2..f5f9fa582 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -778,12 +778,13 @@ drmmode_crtc_set_mode(xf86CrtcPtr crtc, Bool test_only)
 drmmode_crtc_private_ptr other_drmmode_crtc = 
other_crtc->driver_private;
 int lost_outputs = 0;
 int remaining_outputs = 0;
+   int j;
 
 if (other_crtc == crtc)
 continue;
 
-for (i = 0; i < xf86_config->num_output; i++) {
-xf86OutputPtr output = xf86_config->output[i];
+for (j = 0; i < xf86_config->num_output; j++) {
+xf86OutputPtr output = xf86_config->output[j];
 drmmode_output_private_ptr drmmode_output = 
output->driver_private;
 
 if (drmmode_output->current_crtc == other_crtc) {
-- 
2.17.0

___
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: Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

[Daniel Stone]

Hi Mike,

On 5 April 2018 at 09:03, Mike Lothian  wrote:
> I got different behavior with modesetting and the intel ddx

I can try with the Intel DDX later on today.

> Both didn't render anything, but I think one was crashing over and
> over (I think systemd kept restarting it in quick succession)

systemd should log core files to coredumpctl and maintain any output
from services it's started itself in journalctl, so it would be great
to see any output and segfaults if possible.

> I only remember that because when I switched VTs it made it almost
> impossible to type anything as it kept modesetting back to VT1 for a
> moment
>
> That didn't happen with the latest patches (which all seem to be in
> master now) but I did get the freeze that you saw

Right, they are in master now. Which freeze do you mean? If you attach
to the kwin process and see it blocked forever waiting on a reply in
libICE/libSM, this seems to be related to KDE's session management
getting itself tangled, and _not_ anything to do with the rendering
path. For me, the hang inside libICE/libSM was caused by wiping out
all the ksmserver processes still running, as well as my .ICE-unix
directory.

If you are seeing KWin and all the KDE session helper programs alive
and _not_ blocked inside libICE/libSM, a black screen and a KDE mouse
cursor, that's far more interesting and I'd also like to see the X
server's log file as well as any output from KDE in journalctl.

> Be aware that kwin detects when there have been rendering crashes or
> incomplete starts and disables compositing. With compositing disabled
> or set to Xrender everything starts fine

I'm _extremely_ sure that I was using GL compositing, because I was
seeing debug prints that I'd added to Mesa (and the X server DRI3
requests called by Mesa) from a session running only KDE and nothing
else. These debug prints were only ever called when you are an X11
compositing manager.

Cheers,
Daniel
___
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: Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

[Daniel Stone]

Hi Mike,

On 5 April 2018 at 07:10, Mike Lothian  wrote:
> I've just tested with those patches, it still doesn't work without that revert
>
> If you're testing this on kwin can you make sure you're using one of
> the OpenGL options on the renderer rather than XRender

I'm absolutely certain it was using OpenGL because it hit all my debug
prints. I was using KF5-Plasma from Fedora 28: which version did you
have? When you say 'doesn't seem to start', what happens exactly?
Before my last patchset, I saw the KDE cursor but no content rendered.
After applying all three patch series (10 patches total) it started
fine, but it had in the meantime got into some weird in-between state
where KWin hung waiting for an ICE/SM message which never returned. I
had to kill several stray ksmserver processes and also wipe out my
.ICE-unix directory.

Cheers,
Daniel
___
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: [PATCH xserver] modesetting: Fix page flipping under DRI 3.2.

[Daniel Stone]

Hi Mario,

On 4 April 2018 at 17:40, Mario Kleiner <mario.kleiner...@gmail.com> wrote:
> On Wed, Apr 4, 2018 at 6:19 PM, Daniel Stone <dan...@fooishbar.org> wrote:
>> Ugh. I've applied your pageflip patch, lfrb's two-patch atomic fix
>> series and my fix-old-clients series, which for me fixes KDE running
>> with both old and new Mesa. That's just running a Plasma 5 desktop
>> with 'startkde', either single or dual head. Do things work for you if
>> you have all those applied?
>
> I have all applied, but this new series "Fix modifier server / non-mod client"
> of you: https://patchwork.freedesktop.org/series/41142/
>
> If that's the right one, i'll test it later today.

Correct. If you could please try that series, that would be great. I
did see KDE failing before that series, but it seems much happier now.

Cheers,
Daniel
___
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: [PATCH xserver 1/2] modesetting: Use atomic modesetting to set DPMS mode

[Daniel Stone]

Hi Louis-Francis,

On 4 April 2018 at 05:01, Louis-Francis Ratté-Boulianne
<l...@collabora.com> wrote:
> CRTCs and outputs needs to be enabled/disabled when the current
> DPMS mode is changed. We also try to do it in an atomic commit
> when possible.

It would be really nice to separate the code motion from the changes,
into more granular commits than this. I found this a bit hard to
review without referring back to both old and new versions constantly
as I went. Regardless, this series is:
Tested-by: Daniel Stone <dani...@collabora.com>

Cheers,
Daniel
___
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: [PATCH xserver] modesetting: Fix page flipping harder under DRI 3.2.

[Daniel Stone]

On 4 April 2018 at 02:49, Mario Kleiner <mario.kleiner...@gmail.com> wrote:
> Non-atomic kms drivers like radeon-kms (or nouveau-kms with
> default setting of "atomic ioctl disabled") don't export
> any formats, so num_formats == 0.
>
> Some atomic drivers (nouveau-kms with boot param nouveau.atomic=1,
> or intel-kms on, e.g., Linux 4.13) expose num_formats == 0, or
> don't expose any modifiers, so num_modifiers == 0.
>
> Let the drmmode_is_format_supported() check pass in these cases
> to allow page flipping, as it works just fine.
>
> Tested on NV-96 for nouveau, HD-5770 for radeon, Intel Ivybridge
> with Linux 4.13 and drm-next to fix page flipping.

Reviewed-by: Daniel Stone <dani...@collabora.com>

Cheers,
Daniel
___
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: [PATCH xserver] modesetting: Fix page flipping under DRI 3.2.

[Daniel Stone]

Hi Mario,

On 4 April 2018 at 06:22, Mario Kleiner  wrote:
> Ok, so it's probably a mesa bug in the egl dri3 backend caused by the
> new DRI3.1 multibuffers support.
>
> If on current mesa master, in egl_dri2.c:dri2_setup_extensions(), i
> force dri2_dpy->multibuffers_available = false; to disable
> multibuffers, then EGL based compositing under DRI3 works fine again.
> Otherwise i get failure on all gpu's and drivers, as tested with
> ati-ddx,nouveau-ddx,modesetting-ddx under glamor or exa.
>
> This tested on current xserver master and Linux drm-next.

Ugh. I've applied your pageflip patch, lfrb's two-patch atomic fix
series and my fix-old-clients series, which for me fixes KDE running
with both old and new Mesa. That's just running a Plasma 5 desktop
with 'startkde', either single or dual head. Do things work for you if
you have all those applied?

Cheers,
Daniel
___
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: Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

[Daniel Stone]

Hi Mike,

On 4 April 2018 at 09:12, Mike Lothian  wrote:
> Kwin doesn't seem to start with the following commit:
>
> commit abb9b58d1af9a0286162e52ef9db390d0c950fc1
> Author: Thierry Reding 
> Date:   Fri Mar 16 14:24:21 2018 +0100
>
> present: Advertise protocol version 1.2
>
> [...]
>
> Though I think the issue may lie in commit:
>
> commit 6a5d51e0823b43280e3646b7a0c919a3b76146ea
> Author: Emil Velikov 
> Date:   Mon Mar 19 16:04:43 2018 +
>
> present: cap the version returned to the client
>
> [...]
>
> I realise that Kwin will probably need to be modified to work with
> Present 1.2, but I don't think we should be seeing breakage unti that
> happens

I think that's just exposing breakage somewhere else in the chain.
With all these series applied, I've been able to get KDE to start with
'startkde' (running Plasma), both with new and old Mesa:
https://patchwork.freedesktop.org/series/41104/
https://patchwork.freedesktop.org/series/41106/
https://patchwork.freedesktop.org/series/41142/

Cheers,
Daniel
___
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 xserver 5/7] glamor: Reallocate pixmap storage without modifiers if necessary

[Daniel Stone]

If we need a pixmap's storage to be exported to a context in which we
aren't aware of modifiers, reallocate the buffer again without
modifiers.

This makes it possible to run a compositing manager on an old GLX/EGL
stack on top of an X server which allocates internal buffer storage
using exotic modifiers from modifier-aware GBM/EGL/KMS.

Signed-off-by: Daniel Stone <dani...@collabora.com>
Reported-by: Adam Jackson <a...@redhat.com>
---
 glamor/glamor_egl.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index dd6a9a2df..a1e0bc3c9 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -250,7 +250,7 @@ glamor_get_name_from_bo(int gbm_fd, struct gbm_bo *bo, int 
*name)
 }
 
 static Bool
-glamor_make_pixmap_exportable(PixmapPtr pixmap)
+glamor_make_pixmap_exportable(PixmapPtr pixmap, Bool modifiers_ok)
 {
 ScreenPtr screen = pixmap->drawable.pScreen;
 ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
@@ -266,7 +266,8 @@ glamor_make_pixmap_exportable(PixmapPtr pixmap)
 PixmapPtr exported;
 GCPtr scratch_gc;
 
-if (pixmap_priv->image)
+if (pixmap_priv->image &&
+(modifiers_ok || !pixmap_priv->used_modifiers))
 return TRUE;
 
 if (pixmap->drawable.bitsPerPixel != 32) {
@@ -282,7 +283,7 @@ glamor_make_pixmap_exportable(PixmapPtr pixmap)
 format = GBM_FORMAT_ARGB;
 
 #ifdef GBM_BO_WITH_MODIFIERS
-if (glamor_egl->dmabuf_capable) {
+if (modifiers_ok && glamor_egl->dmabuf_capable) {
 uint32_t num_modifiers;
 uint64_t *modifiers = NULL;
 
@@ -370,7 +371,7 @@ glamor_egl_fds_from_pixmap(ScreenPtr screen, PixmapPtr 
pixmap, int *fds,
 int i;
 #endif
 
-if (!glamor_make_pixmap_exportable(pixmap))
+if (!glamor_make_pixmap_exportable(pixmap, TRUE))
 return 0;
 
 bo = glamor_gbm_bo_from_pixmap(screen, pixmap);
@@ -411,7 +412,7 @@ glamor_egl_fd_name_from_pixmap(ScreenPtr screen,
 
 glamor_egl = glamor_egl_get_screen_private(xf86ScreenToScrn(screen));
 
-if (!glamor_make_pixmap_exportable(pixmap))
+if (!glamor_make_pixmap_exportable(pixmap, FALSE))
 goto failure;
 
 bo = glamor_gbm_bo_from_pixmap(screen, pixmap);
-- 
2.17.0

___
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 xserver 6/7] glamor: Fall back to non-modifier allocations

[Daniel Stone]

If we try to allocate with particular modifiers but it fails, try to
fall back to non-modifier allocations.

Signed-off-by: Daniel Stone <dani...@collabora.com>
Reported-by: Adam Jackson <a...@redhat.com>
---
 glamor/glamor_egl.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index a1e0bc3c9..2dffbb8dc 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -261,7 +261,7 @@ glamor_make_pixmap_exportable(PixmapPtr pixmap, Bool 
modifiers_ok)
 unsigned width = pixmap->drawable.width;
 unsigned height = pixmap->drawable.height;
 uint32_t format;
-struct gbm_bo *bo;
+struct gbm_bo *bo = NULL;
 Bool used_modifiers = FALSE;
 PixmapPtr exported;
 GCPtr scratch_gc;
@@ -295,8 +295,9 @@ glamor_make_pixmap_exportable(PixmapPtr pixmap, Bool 
modifiers_ok)
 used_modifiers = TRUE;
 free(modifiers);
 }
-else
 #endif
+
+if (!bo)
 {
 bo = gbm_bo_create(glamor_egl->gbm, width, height, format,
 #ifdef GLAMOR_HAS_GBM_LINEAR
-- 
2.17.0

___
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 xserver 7/7] glamor: Add fd_from_pixmap hook

[Daniel Stone]

Add a fd_from_pixmap (singular) hook to go with fds_from_pixmap, which
will ensure that the pixmap is allocated without modifiers and is thus
exportable to non-modifier-aware clients.

This makes it possible to run a compositing manager on an old GLX/EGL
stack on top of an X server which allocates internal buffer storage
using exotic modifiers from modifier-aware GBM/EGL/KMS.

Signed-off-by: Daniel Stone <dani...@collabora.com>
Reported-by: Adam Jackson <a...@redhat.com>
---
 glamor/glamor_egl.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index 2dffbb8dc..5a47dbd91 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -402,6 +402,32 @@ glamor_egl_fds_from_pixmap(ScreenPtr screen, PixmapPtr 
pixmap, int *fds,
 #endif
 }
 
+static int
+glamor_egl_fd_from_pixmap(ScreenPtr screen, PixmapPtr pixmap,
+  CARD16 *stride, CARD32 *size)
+{
+#ifdef GLAMOR_HAS_GBM
+struct gbm_bo *bo;
+int fd;
+
+if (!glamor_make_pixmap_exportable(pixmap, FALSE))
+return -1;
+
+bo = glamor_gbm_bo_from_pixmap(screen, pixmap);
+if (!bo)
+return -1;
+
+fd = gbm_bo_get_fd(bo);
+*stride = gbm_bo_get_stride(bo);
+*size = *stride * gbm_bo_get_height(bo);
+gbm_bo_destroy(bo);
+
+return fd;
+#else
+return -1;
+#endif
+}
+
 int
 glamor_egl_fd_name_from_pixmap(ScreenPtr screen,
PixmapPtr pixmap,
@@ -775,6 +801,7 @@ static dri3_screen_info_rec glamor_dri3_info = {
 .version = 2,
 .open_client = glamor_dri3_open_client,
 .pixmap_from_fds = glamor_pixmap_from_fds,
+.fd_from_pixmap = glamor_egl_fd_from_pixmap,
 .fds_from_pixmap = glamor_egl_fds_from_pixmap,
 .get_formats = glamor_get_formats,
 .get_modifiers = glamor_get_modifiers,
-- 
2.17.0

___
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 xserver 4/7] glamor: Push make_exportable into callers

[Daniel Stone]

Rather than calling make_exportable from the get_bo entrypoint, make
sure that someone has already explicitly requested the pixmap be
exportable.

This is technically an ABI break in that it changes observable
behaviour, but no driver other than modesetting has ever used get_bo.

Signed-off-by: Daniel Stone <dani...@collabora.com>
Reported-by: Adam Jackson <a...@redhat.com>
---
 glamor/glamor_egl.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index 0e771b6d2..dd6a9a2df 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -351,7 +351,7 @@ glamor_gbm_bo_from_pixmap(ScreenPtr screen, PixmapPtr 
pixmap)
 struct glamor_pixmap_private *pixmap_priv =
 glamor_get_pixmap_private(pixmap);
 
-if (!glamor_make_pixmap_exportable(pixmap))
+if (!pixmap_priv->image)
 return NULL;
 
 return gbm_bo_import(glamor_egl->gbm, GBM_BO_IMPORT_EGL_IMAGE,
@@ -411,6 +411,9 @@ glamor_egl_fd_name_from_pixmap(ScreenPtr screen,
 
 glamor_egl = glamor_egl_get_screen_private(xf86ScreenToScrn(screen));
 
+if (!glamor_make_pixmap_exportable(pixmap))
+goto failure;
+
 bo = glamor_gbm_bo_from_pixmap(screen, pixmap);
 if (!bo)
 goto failure;
-- 
2.17.0

___
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 xserver 3/7] glamor: Track if BO allocation used modifiers

[Daniel Stone]

Keep track of whether or not we fed modifiers into GBM when we allocated
a BO. We'll use this later inside Glamor, to reallocate buffer storage
if we allocate buffer storage using modifiers, and a non-modifier-aware
client requests an export of that pixmap.

This makes it possible to run a compositing manager on an old GLX/EGL
stack on top of an X server which allocates internal buffer storage
using exotic modifiers from modifier-aware GBM/EGL/KMS.

Signed-off-by: Daniel Stone <dani...@collabora.com>
Reported-by: Adam Jackson <a...@redhat.com>
---
 glamor/glamor.h   |  3 +-
 glamor/glamor_egl.c   | 29 +--
 glamor/glamor_priv.h  |  1 +
 .../drivers/modesetting/drmmode_display.c |  3 +-
 4 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/glamor/glamor.h b/glamor/glamor.h
index 7b5676226..b0b23d3a3 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -391,7 +391,8 @@ extern _X_EXPORT Bool 
glamor_egl_create_textured_pixmap(PixmapPtr pixmap,
  */
 extern _X_EXPORT Bool
  glamor_egl_create_textured_pixmap_from_gbm_bo(PixmapPtr pixmap,
-   struct gbm_bo *bo);
+   struct gbm_bo *bo,
+   Bool used_modifiers);
 
 #endif
 
diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index f82fa519b..0e771b6d2 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -150,7 +150,8 @@ glamor_egl_create_textured_screen(ScreenPtr screen, int 
handle, int stride)
 }
 
 static void
-glamor_egl_set_pixmap_image(PixmapPtr pixmap, EGLImageKHR image)
+glamor_egl_set_pixmap_image(PixmapPtr pixmap, EGLImageKHR image,
+Bool used_modifiers)
 {
 struct glamor_pixmap_private *pixmap_priv =
 glamor_get_pixmap_private(pixmap);
@@ -165,6 +166,7 @@ glamor_egl_set_pixmap_image(PixmapPtr pixmap, EGLImageKHR 
image)
 eglDestroyImageKHR(glamor_egl->display, old);
 }
 pixmap_priv->image = image;
+pixmap_priv->used_modifiers = used_modifiers;
 }
 
 Bool
@@ -204,7 +206,8 @@ glamor_egl_create_textured_pixmap(PixmapPtr pixmap, int 
handle, int stride)
 
 Bool
 glamor_egl_create_textured_pixmap_from_gbm_bo(PixmapPtr pixmap,
-  struct gbm_bo *bo)
+  struct gbm_bo *bo,
+  Bool used_modifiers)
 {
 ScreenPtr screen = pixmap->drawable.pScreen;
 ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
@@ -229,7 +232,7 @@ glamor_egl_create_textured_pixmap_from_gbm_bo(PixmapPtr 
pixmap,
 glamor_create_texture_from_image(screen, image, );
 glamor_set_pixmap_type(pixmap, GLAMOR_TEXTURE_DRM);
 glamor_set_pixmap_texture(pixmap, texture);
-glamor_egl_set_pixmap_image(pixmap, image);
+glamor_egl_set_pixmap_image(pixmap, image, used_modifiers);
 ret = TRUE;
 
  done:
@@ -259,6 +262,7 @@ glamor_make_pixmap_exportable(PixmapPtr pixmap)
 unsigned height = pixmap->drawable.height;
 uint32_t format;
 struct gbm_bo *bo;
+Bool used_modifiers = FALSE;
 PixmapPtr exported;
 GCPtr scratch_gc;
 
@@ -286,6 +290,8 @@ glamor_make_pixmap_exportable(PixmapPtr pixmap)
 
 bo = gbm_bo_create_with_modifiers(glamor_egl->gbm, width, height,
   format, modifiers, num_modifiers);
+if (bo)
+used_modifiers = TRUE;
 free(modifiers);
 }
 else
@@ -309,7 +315,8 @@ glamor_make_pixmap_exportable(PixmapPtr pixmap)
 exported = screen->CreatePixmap(screen, 0, 0, pixmap->drawable.depth, 0);
 screen->ModifyPixmapHeader(exported, width, height, 0, 0,
gbm_bo_get_stride(bo), NULL);
-if (!glamor_egl_create_textured_pixmap_from_gbm_bo(exported, bo)) {
+if (!glamor_egl_create_textured_pixmap_from_gbm_bo(exported, bo,
+   used_modifiers)) {
 xf86DrvMsg(scrn->scrnIndex, X_ERROR,
"Failed to make %dx%dx%dbpp pixmap from GBM bo\n",
width, height, pixmap->drawable.bitsPerPixel);
@@ -452,7 +459,7 @@ glamor_back_pixmap_from_fd(PixmapPtr pixmap,
 
 screen->ModifyPixmapHeader(pixmap, width, height, 0, 0, stride, NULL);
 
-ret = glamor_egl_create_textured_pixmap_from_gbm_bo(pixmap, bo);
+ret = glamor_egl_create_textured_pixmap_from_gbm_bo(pixmap, bo, FALSE);
 gbm_bo_destroy(bo);
 return ret;
 }
@@ -509,7 +516,7 @@ glamor_pixmap_from_fds(ScreenPtr screen,
 bo = gbm_bo_import(glamor_egl->gbm, GBM_BO_IMPORT_FD_MODIFIER, 
_data, 0);
 if (bo) {
 screen->ModifyPixmapHeader(pixmap, width, height, 0, 0, 
strides[0], NULL);
-ret = glamor_egl_create_textured_pixmap_from_gbm_bo(pixmap, bo);
+  

[PATCH xserver 2/7] drmmode: Track if BO allocation used modifiers

[Daniel Stone]

Keep track of whether or not we fed modifiers into GBM when we allocated
a BO. We'll use this later inside Glamor, to reallocate buffer storage
if we allocate buffer storage using modifiers, and a non-modifier-aware
client requests an export of that pixmap.

This makes it possible to run a compositing manager on an old GLX/EGL
stack on top of an X server which allocates internal buffer storage
using exotic modifiers from modifier-aware GBM/EGL/KMS.

Signed-off-by: Daniel Stone <dani...@collabora.com>
Reported-by: Adam Jackson <a...@redhat.com>
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 5 -
 hw/xfree86/drivers/modesetting/drmmode_display.h | 1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index fc1aef2b6..aeb44263b 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -1022,13 +1022,16 @@ drmmode_create_bo(drmmode_ptr drmmode, drmmode_bo *bo,
format, modifiers,
num_modifiers);
 free(modifiers);
-if (bo->gbm)
+if (bo->gbm) {
+bo->used_modifiers = TRUE;
 return TRUE;
+}
 }
 #endif
 
 bo->gbm = gbm_bo_create(drmmode->gbm, width, height, format,
 GBM_BO_USE_RENDERING | GBM_BO_USE_SCANOUT);
+bo->used_modifiers = FALSE;
 return bo->gbm != NULL;
 }
 #endif
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.h 
b/hw/xfree86/drivers/modesetting/drmmode_display.h
index 4e1e013ff..74954b853 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.h
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.h
@@ -75,6 +75,7 @@ typedef struct {
 uint32_t height;
 struct dumb_bo *dumb;
 #ifdef GLAMOR_HAS_GBM
+Bool used_modifiers;
 struct gbm_bo *gbm;
 #endif
 } drmmode_bo;
-- 
2.17.0

___
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 xserver 0/7] Fix modifier server / non-mod client

[Daniel Stone]

Hi,
This series fixes running a modifier-aware server with a
non-modifier-aware DRI3 compositing manager. We'd thought of and dealt
with the case where we had legacy/non-modifier-aware clients, but
slipped up with non-modifier-aware compositing managers.

Glamor would allocate pixmaps with the full set of modifiers available
to it from GBM/EGL, then try to export them to a non-modifier-aware
client. This may fail outright (e.g. when the modifier adds a plane), or
result in garbage (with an exotic modifier selection the client can't
infer via magic back channels).

When we get a request to export a buffer to a non-modifier-aware client
in Glamor, forcibly reallocate it with no explicit modifiers, so we get
something that can be exported to legacy clients.

Cheers,
Daniel


___
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 xserver 1/7] dri3: Use single-FD screen call for single-FD request

[Daniel Stone]

When importing client buffers into Pixmaps, we can use the fds_to_pixmap
hook for both single-FD and multi-FD client requests without any harm.

For the other direction of exporting Pixmap buffers to client FDs,
create a new helper which calls the old pixmap_to_fd hook if available.
This allows the implementation to ensure that the Pixmap storage is
accessible to clients not aware of multiple planes or modifiers, e.g. by
reallocating and copying.

This makes it possible to run a compositing manager on an old GLX/EGL
stack on top of an X server which allocates internal buffer storage
using exotic modifiers from modifier-aware GBM/EGL/KMS.

Signed-off-by: Daniel Stone <dani...@collabora.com>
Reported-by: Adam Jackson <a...@redhat.com>
---
 dri3/dri3_priv.h|  3 +++
 dri3/dri3_request.c | 16 +---
 dri3/dri3_screen.c  | 40 
 3 files changed, 48 insertions(+), 11 deletions(-)

diff --git a/dri3/dri3_priv.h b/dri3/dri3_priv.h
index 8447680ba..d86f06be0 100644
--- a/dri3/dri3_priv.h
+++ b/dri3/dri3_priv.h
@@ -83,6 +83,9 @@ dri3_pixmap_from_fds(PixmapPtr *ppixmap, ScreenPtr screen, 
CARD8 num_fds, int *f
  CARD16 width, CARD16 height, CARD32 *strides, CARD32 
*offsets,
  CARD8 depth, CARD8 bpp, CARD64 modifier);
 
+int
+dri3_fd_from_pixmap(PixmapPtr pixmap, CARD16 *stride, CARD32 *size);
+
 int
 dri3_fds_from_pixmap(PixmapPtr pixmap, int *fds,
  CARD32 *strides, CARD32 *offsets,
diff --git a/dri3/dri3_request.c b/dri3/dri3_request.c
index fc258711b..2d3deb282 100644
--- a/dri3/dri3_request.c
+++ b/dri3/dri3_request.c
@@ -212,10 +212,7 @@ proc_dri3_buffer_from_pixmap(ClientPtr client)
 .length = 0,
 };
 int rc;
-int num_fds;
-int fds[4];
-uint32_t strides[4], offsets[4];
-uint64_t modifier;
+int fd;
 PixmapPtr pixmap;
 
 REQUEST_SIZE_MATCH(xDRI3BufferFromPixmapReq);
@@ -231,13 +228,10 @@ proc_dri3_buffer_from_pixmap(ClientPtr client)
 rep.depth = pixmap->drawable.depth;
 rep.bpp = pixmap->drawable.bitsPerPixel;
 
-num_fds = dri3_fds_from_pixmap(pixmap, fds, strides, offsets, );
-if (num_fds != 1)
+fd = dri3_fd_from_pixmap(pixmap, , );
+if (fd == -1)
 return BadPixmap;
 
-rep.stride = (CARD16) strides[0];
-rep.size = rep.stride * rep.height;
-
 if (client->swapped) {
 swaps();
 swapl();
@@ -246,8 +240,8 @@ proc_dri3_buffer_from_pixmap(ClientPtr client)
 swaps();
 swaps();
 }
-if (WriteFdToClient(client, fds[0], TRUE) < 0) {
-close(fds[0]);
+if (WriteFdToClient(client, fd, TRUE) < 0) {
+close(fd);
 return BadAlloc;
 }
 
diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
index df40f8281..41595f412 100644
--- a/dri3/dri3_screen.c
+++ b/dri3/dri3_screen.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static inline Bool has_open(dri3_screen_info_ptr info) {
 if (info == NULL)
@@ -124,6 +125,45 @@ dri3_fds_from_pixmap(PixmapPtr pixmap, int *fds,
 }
 }
 
+int
+dri3_fd_from_pixmap(PixmapPtr pixmap, CARD16 *stride, CARD32 *size)
+{
+ScreenPtr   screen = pixmap->drawable.pScreen;
+dri3_screen_priv_ptrds = dri3_screen_priv(screen);
+dri3_screen_info_ptrinfo = ds->info;
+CARD32  strides[4];
+CARD32  offsets[4];
+CARD64  modifier;
+int fds[4];
+int num_fds;
+
+if (!info)
+return -1;
+
+/* Preferentially use the old interface, allowing the implementation to
+ * ensure the buffer is in a single-plane format which doesn't need
+ * modifiers. */
+if (info->fd_from_pixmap != NULL)
+return (*info->fd_from_pixmap)(screen, pixmap, stride, size);
+
+if (info->version < 2 || info->fds_from_pixmap == NULL)
+return -1;
+
+/* If using the new interface, make sure that it's a single plane starting
+ * at 0 within the BO. We don't check the modifier, as the client may
+ * have an auxiliary mechanism for determining the modifier itself. */
+num_fds = info->fds_from_pixmap(screen, pixmap, fds, strides, offsets,
+);
+if (num_fds != 1 || offsets[0] != 0) {
+int i;
+for (i = 0; i < num_fds; i++)
+close(fds[i]);
+return -1;
+}
+
+return fds[0];
+}
+
 static int
 cache_formats_and_modifiers(ScreenPtr screen)
 {
-- 
2.17.0

___
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: [PATCH xserver] modesetting: Fix page flipping under DRI 3.2.

[Daniel Stone]

On 3 April 2018 at 16:36, Mario Kleiner  wrote:
> Btw. another new problem, which i haven't had time to track down at
> all is that desktop composition under EGL seems to be totally broken.
> Tested on KUbuntu 16.0.4 LTS with xserver master + mesa master last
> thursday with whatever KDE Plasma 5 version ships with 16.04.
> Compositing with XRender accel or GLX + OpenGL 2/3 works fine. Could
> be modesetting, or glamor, or mesa.
>
> I get sometimes black screen, or sometimes massive corruption with
> pixel trash like if it displays random buffer contents from
> uninitialized buffers under modesetting-ddx + DRI3, on all kms
> drivers. Can anybody confirm this?

It is seeming like the compression support in the Intel driver has
regressed. If you edit mesa/src/mesa/drivers/dri/i965/intel_screen.c
and remove I915_FORMAT_MOD_Y_TILED_CCS from the supported_modifiers[]
array, does that resolve the issue?

Cheers,
Daniel
___
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: [PATCH xserver] modesetting: Fix page flipping under DRI 3.2.

[Daniel Stone]

Hi Mario,

On 3 April 2018 at 15:44, Mario Kleiner  wrote:
> Those are fine according to my testing, they fix mode-setting under
> both depth24 and 30.
>
> However as testing shows, still not sufficient for pageflipping if the
> kms driver doesn't support full atomic (as tested on radeon-kms, and
> as well under nouveau-kms without the nouveau.atomic=1 kernel boot
> parameter). Even with atomic (nouveau.atomic=1, or intel-kms)
> pageflipping doesn't get used when it should be if the driver exposes
> num_modifiers==0, e.g., Intel Ivybridge under Linux 4.13 (whereas
> Linux 4.15-something was fine under Intel).
>
> The following snippet made pageflipping work on radeon-kms, intel-kms
> (Tested Linux 4.13 and some slightly outdated drm-next), nouveau-kms
> with/without nouveau.atomic=1 module parameter. I can turn it into a
> proper patch later today:

Thanks for tracking this down! That looks like the right thing to do,
modulo the obvious debug lines.

Cheers,
Daniel
___
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: [PATCH xserver] modesetting: Fix up some XXX from removing GLAMOR_HAS_DRM_*

[Daniel Stone]

Hi Mario,

On 29 March 2018 at 00:47, Mario Kleiner  wrote:
> On Thu, Mar 22, 2018 at 7:47 PM, Adam Jackson  wrote:
>> @@ -2244,18 +2247,19 @@ drmmode_output_dpms(xf86OutputPtr output, int mode)
>>  {
>>  drmmode_output_private_ptr drmmode_output = output->driver_private;
>>  xf86CrtcPtr crtc = output->crtc;
>> +modesettingPtr ms = modesettingPTR(crtc->scrn);
>
> --> This assignment above makes the X-Server crash, if output->crtc is
> NULL, and therefore crtc->scrn is a NULL ptr deref.
> output->crtc == NULL can happen from some call paths, e.g., whenever
> xf86DisableUnusedFunctions() gets called and decides to dpms off an
> output.

Ugh. It looks like we should be able to just directly use output->scrn
instead of crtc->scrn in that offending line; does that work for you?

Cheers,
Daniel
___
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: [PATCH xserver] modesettings: Use actual crtc position for pageflip

[Daniel Stone]

On 29 March 2018 at 08:42, Olivier Fourdan <ofour...@redhat.com> wrote:
> Otherwise the same content is shown on all outputs.

Yeah, good point.

Reviewed-by: Daniel Stone <dani...@collabora.comm>
___
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: [PATCH xserver 2/2] modesetting: Fix reported size when using atomic modesetting

[Daniel Stone]

On 29 March 2018 at 08:46, Olivier Fourdan <ofour...@redhat.com> wrote:
> Looks good to me *but* this is not sufficient because
> do_queue_flip_on_crtc() calls drmmode_crtc_set_fb() with (x=0,y=0) for any
> CRTC regardless of its actual location...
>
> So, it also requires https://patchwork.freedesktop.org/series/40860/ and
> with this, this patch is:
>
> Tested-by: Olivier Fourdan <ofour...@redhat.com>
> Reviewed-by: Olivier Fourdan <ofour...@redhat.com>

Reviewed-by: Daniel Stone <dani...@collabora.com>
___
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: [PATCH xserver 1/2] modesetting: Ignore alpha channel when importing BOs for modesetting

[Daniel Stone]

On 29 March 2018 at 08:43, Olivier Fourdan <ofour...@redhat.com> wrote:
> Looks good to me.
>
> Tested-by: Olivier Fourdan <ofour...@redhat.com>
> Reviewed-by: Olivier Fourdan <ofour...@redhat.com>

And to me:
Reviewed-by: Daniel Stone <dani...@collabora.com>
___
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: [PATCH xserver 3/3] modesetting/drmmode: Use drmModeGetFB2

[Daniel Stone]

Hi Emil,

On 26 March 2018 at 16:22, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 23 March 2018 at 13:50, Daniel Stone <dani...@collabora.com> wrote:
>> Much like AddFB -> AddFB2, GetFB2 lets us get multiple buffers back as
>> well as modifier information. This lets us use -background none with
>> multiplanar formats, or modifiers which can't be inferred via a magic
>> side channel.
>>
> AFAICT there's nothing special (or wrong) with the new API.
>
> The flags field is a bit of an open question - should Xserver or
> libdrm manage the value passed to the kernel?
> Analogously - should we pass the flags back to the user (drmModeFB2::flags)?
>
> Current design seems perfectly fine IMHO, although others might disagree.

Thanks for looking at this! I think the flags question is a good one,
and that we should probably make the field RW: userspace declaring
what it supports (analagous to AddFB2), and the kernel overwriting
that with the intersection of what userspace and the kernel support
(not analogous, but since it's a getter rather than an add ...).

>> @@ -1090,31 +1094,63 @@ create_pixmap_for_fbcon(drmmode_ptr drmmode, 
>> ScrnInfoPtr pScrn, int fbcon_id)
>>  if (pixmap)
>>  return pixmap;
>>
>> -fbcon = drmModeGetFB(drmmode->fd, fbcon_id);
>> -if (fbcon == NULL)
>> -return NULL;
>> +fbcon2 = drmModeGetFB2(drmmode->fd, fbcon_id);
>> +if (fbcon2) {
> Declare and initialize fbcon2 in one go - C99 feature that everyone
> has (even the people who use MSVC to build Xserver & friends).
> Then wrap the whole fbcon2 hunk in a #ifdef HAVE_GETFB2 + add a
> configure/meson check.

Sure; the only reason I didn't add an ifdef check is because there's
no version released with it yet.

> Alternatively add a weak drmModeGetFB2 function which returns NULL and
> forget all the above ;-)

If you have a good suggestion for implementing weak symbols then I'm
all ears, but last I saw from the Mesa experience no-one could figure
out how to do it properly.

>> +width = fbcon2->width;
>> +height = fbcon2->height;
>> +memcpy(handles, fbcon2->handles, sizeof(handles));
>> +memcpy(strides, fbcon2->pitches, sizeof(strides));
>> +memcpy(offsets, fbcon2->offsets, sizeof(offsets));
>> +modifier = fbcon2->modifier;
>> +switch (fbcon2->pixel_format) {
>> +case DRM_FORMAT_RGB565:
>> +depth = 16;
> Missing bpp?

Correct.

> Idea: Instead of introducing another format <> {depth, bpp} mapping,
> might as well add some helpers?

I can only see that mapping inside drmmode_create_bo, which is
different as it creates everything with an alpha channel, i.e.
s/XRGB/ARGB/. Are there some others I'm missing?

>> +break;
>> +case DRM_FORMAT_XRGB:
>> +depth = 24;
>> +bpp = 32;
>> +break;
>> +case DRM_FORMAT_XRGB2101010:
>> +depth = 30;
>> +bpp = 32;
>> +default:
>> +break;
> Error instead of silently continuing?

Sure.

Cheers,
Daniel
___
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: [PATCH xserver 2/3] modesetting/drmmode: Use glamor_pixmap_from_fds

[Daniel Stone]

Hi,

On 26 March 2018 at 16:11, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 23 March 2018 at 13:50, Daniel Stone <dani...@collabora.com> wrote:
>> +for (i = 0; i < 4 && handles[i]; i++) {
>> +err = drmPrimeHandleToFD(drmmode->fd, handles[i], O_CLOEXEC, 
>> [i]);
>> +if (err != 0)
>> +return 0;
> Close the existing fds ones on error?
>
> With the fd leak plugged (regardless of the nit)
> Reviewed-by: Emil Velikov <emil.veli...@collabora.com>

Right you are; it can also be fixed by s/out_free_fb/out_close_fds/ in
the caller's failure path (below the 'Failed to make prime FD for
handle' message).

> Aside: there's plenty of duplication in the area + some partial depth
> <> format mappings.

There sure is, but I decided to leave those as-is for now.

Cheers,
Daniel
___
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 xserver 2/3] modesetting/drmmode: Use glamor_pixmap_from_fds

[Daniel Stone]

glamor_pixmap_from_fds saves us the trouble of creating the pixmap and
dealing with its header ourselves; instead we pass the whole thing off
to Glamor.

This requires us to provide FDs rather than handles for the import, but
Glamor was already doing that internally, so no functional change.

Signed-off-by: Daniel Stone <dani...@collabora.com>
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 52 +++-
 1 file changed, 42 insertions(+), 10 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 4b22abd0f..39ed16f98 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -30,6 +30,7 @@
 #endif
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1058,6 +1059,21 @@ drmmode_crtc_dpms(xf86CrtcPtr crtc, int mode)
 drmmode_crtc->dpms_mode = mode;
 }
 
+static int
+handles_to_fds(drmmode_ptr drmmode, uint32_t *handles, int *fds)
+{
+int err;
+int i;
+
+for (i = 0; i < 4 && handles[i]; i++) {
+err = drmPrimeHandleToFD(drmmode->fd, handles[i], O_CLOEXEC, [i]);
+if (err != 0)
+return 0;
+}
+
+return i;
+}
+
 #ifdef GLAMOR_HAS_GBM
 static PixmapPtr
 create_pixmap_for_fbcon(drmmode_ptr drmmode, ScrnInfoPtr pScrn, int fbcon_id)
@@ -1065,7 +1081,11 @@ create_pixmap_for_fbcon(drmmode_ptr drmmode, ScrnInfoPtr 
pScrn, int fbcon_id)
 PixmapPtr pixmap = drmmode->fbcon_pixmap;
 drmModeFBPtr fbcon;
 ScreenPtr pScreen = xf86ScrnToScreen(pScrn);
-Bool ret;
+uint32_t handles[4] = { 0, };
+CARD32 strides[4] = { 0, }, offsets[4] = { 0, };
+int fds[4] = { -1, -1, -1, -1 };
+int num_fds;
+int i;
 
 if (pixmap)
 return pixmap;
@@ -1079,19 +1099,31 @@ create_pixmap_for_fbcon(drmmode_ptr drmmode, 
ScrnInfoPtr pScrn, int fbcon_id)
 fbcon->height != pScrn->virtualY)
 goto out_free_fb;
 
-pixmap = drmmode_create_pixmap_header(pScreen, fbcon->width,
-  fbcon->height, fbcon->depth,
-  fbcon->bpp, fbcon->pitch, NULL);
-if (!pixmap)
+/* GBM doesn't have an import path from handles, so we make a
+ * dma-buf fd from it and then go through that.
+ */
+handles[0] = fbcon->handle;
+num_fds = handles_to_fds(drmmode, handles, fds);
+if (num_fds == 0) {
+xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
+   "Failed to make prime FD for handle: %d\n", errno);
 goto out_free_fb;
-
-ret = glamor_egl_create_textured_pixmap(pixmap, fbcon->handle, 
fbcon->pitch);
-if (!ret) {
-  FreePixmap(pixmap);
-  pixmap = NULL;
 }
+strides[0] = fbcon->pitch;
+
+pixmap = glamor_pixmap_from_fds(pScreen, num_fds, fds,
+fbcon->width, fbcon->height,
+strides, offsets, fbcon->depth,
+fbcon->bpp, DRM_FORMAT_MOD_INVALID);
+if (!pixmap)
+goto out_close_fds;
 
 drmmode->fbcon_pixmap = pixmap;
+out_close_fds:
+for (i = 0; i < ARRAY_SIZE(fds); i++) {
+if (fds[i] != -1)
+close(fds[i]);
+}
 out_free_fb:
 drmModeFreeFB(fbcon);
 return pixmap;
-- 
2.16.2

___
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 xserver 0/3] Use DRM GetFB2 ioctl

[Daniel Stone]

Hi,
This short patchset makes modesetting use the shiny, new, and completely
not at all merged GetFB2 DRM ioctl:
https://lists.freedesktop.org/archives/dri-devel/2018-March/170512.html

When starting Xorg with -background none, it uses GetFB to interrogate
the current framebuffer, importing it into a Glamor texture so it can
copy back to its own storage. Unfortunately, if your buffer was
multi-planar (e.g. new Intel with auxiliary compression buffer), or just
too exotic to be described without a modifier (etnaviv in tiled mode),
GetFB fell short of what we actually needed.

GetFB2 is the equivalent to AddFB2 (or AddFB2WithModifiers; both the
same from an ioctl point of view), so this ports modesetting to use that
where available and use with more complex buffers.

The kernel ABI rules require positive review from real userspace (not
random hacked-up libdrm tests) before merging. Given that, I'd
appreciate someone taking a look at the use of GetFB2 here, and
following up with a statement that they think the ABI is actually good
and long-term usable for what Xorg needs. (Or, well, some kind of
constructive criticism.)

Happy new-kernel-ABI Friday!

Cheers,
Daniel

___
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 xserver 1/3] modesetting/drmmode: Remove unused flink call

[Daniel Stone]

We don't use flink in the GetFB import path anymore, as we do an
FD-based import instead.

Signed-off-by: Daniel Stone <dani...@collabora.com>
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 6f636ba7b..4b22abd0f 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -1064,7 +1064,6 @@ create_pixmap_for_fbcon(drmmode_ptr drmmode, ScrnInfoPtr 
pScrn, int fbcon_id)
 {
 PixmapPtr pixmap = drmmode->fbcon_pixmap;
 drmModeFBPtr fbcon;
-struct drm_gem_flink flink;
 ScreenPtr pScreen = xf86ScrnToScreen(pScrn);
 Bool ret;
 
@@ -1080,12 +1079,6 @@ create_pixmap_for_fbcon(drmmode_ptr drmmode, ScrnInfoPtr 
pScrn, int fbcon_id)
 fbcon->height != pScrn->virtualY)
 goto out_free_fb;
 
-flink.handle = fbcon->handle;
-if (ioctl(drmmode->fd, DRM_IOCTL_GEM_FLINK, ) < 0) {
-xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "Couldn't flink fbcon handle\n");
-goto out_free_fb;
-}
-
 pixmap = drmmode_create_pixmap_header(pScreen, fbcon->width,
   fbcon->height, fbcon->depth,
   fbcon->bpp, fbcon->pitch, NULL);
-- 
2.16.2

___
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 xserver 3/3] modesetting/drmmode: Use drmModeGetFB2

[Daniel Stone]

Much like AddFB -> AddFB2, GetFB2 lets us get multiple buffers back as
well as modifier information. This lets us use -background none with
multiplanar formats, or modifiers which can't be inferred via a magic
side channel.

Signed-off-by: Daniel Stone <dani...@collabora.com>
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 65 ++--
 1 file changed, 50 insertions(+), 15 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 39ed16f98..82ea49386 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -1080,9 +1080,13 @@ create_pixmap_for_fbcon(drmmode_ptr drmmode, ScrnInfoPtr 
pScrn, int fbcon_id)
 {
 PixmapPtr pixmap = drmmode->fbcon_pixmap;
 drmModeFBPtr fbcon;
+drmModeFB2Ptr fbcon2;
 ScreenPtr pScreen = xf86ScrnToScreen(pScrn);
 uint32_t handles[4] = { 0, };
 CARD32 strides[4] = { 0, }, offsets[4] = { 0, };
+uint64_t modifier;
+int width, height;
+int depth = 0, bpp = 0;
 int fds[4] = { -1, -1, -1, -1 };
 int num_fds;
 int i;
@@ -1090,31 +1094,63 @@ create_pixmap_for_fbcon(drmmode_ptr drmmode, 
ScrnInfoPtr pScrn, int fbcon_id)
 if (pixmap)
 return pixmap;
 
-fbcon = drmModeGetFB(drmmode->fd, fbcon_id);
-if (fbcon == NULL)
-return NULL;
+fbcon2 = drmModeGetFB2(drmmode->fd, fbcon_id);
+if (fbcon2) {
+width = fbcon2->width;
+height = fbcon2->height;
+memcpy(handles, fbcon2->handles, sizeof(handles));
+memcpy(strides, fbcon2->pitches, sizeof(strides));
+memcpy(offsets, fbcon2->offsets, sizeof(offsets));
+modifier = fbcon2->modifier;
+switch (fbcon2->pixel_format) {
+case DRM_FORMAT_RGB565:
+depth = 16;
+break;
+case DRM_FORMAT_XRGB:
+depth = 24;
+bpp = 32;
+break;
+case DRM_FORMAT_XRGB2101010:
+depth = 30;
+bpp = 32;
+default:
+break;
+}
+drmModeFreeFB2(fbcon2);
+}
+else {
+fbcon = drmModeGetFB(drmmode->fd, fbcon_id);
+if (fbcon == NULL)
+return NULL;
+
+width = fbcon->width;
+height = fbcon->height;
+handles[0] = fbcon->handle;
+strides[0] = fbcon->pitch;
+modifier = DRM_FORMAT_MOD_INVALID;
+depth = fbcon->depth;
+bpp = fbcon->bpp;
 
-if (fbcon->depth != pScrn->depth ||
-fbcon->width != pScrn->virtualX ||
-fbcon->height != pScrn->virtualY)
-goto out_free_fb;
+drmModeFreeFB(fbcon);
+}
+
+if (depth != pScrn->depth ||
+width != pScrn->virtualX || height != pScrn->virtualY)
+goto out;
 
 /* GBM doesn't have an import path from handles, so we make a
  * dma-buf fd from it and then go through that.
  */
-handles[0] = fbcon->handle;
 num_fds = handles_to_fds(drmmode, handles, fds);
 if (num_fds == 0) {
 xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
"Failed to make prime FD for handle: %d\n", errno);
-goto out_free_fb;
+goto out;
 }
-strides[0] = fbcon->pitch;
 
 pixmap = glamor_pixmap_from_fds(pScreen, num_fds, fds,
-fbcon->width, fbcon->height,
-strides, offsets, fbcon->depth,
-fbcon->bpp, DRM_FORMAT_MOD_INVALID);
+width, height, strides, offsets,
+depth, bpp, modifier);
 if (!pixmap)
 goto out_close_fds;
 
@@ -1124,8 +1160,7 @@ out_close_fds:
 if (fds[i] != -1)
 close(fds[i]);
 }
-out_free_fb:
-drmModeFreeFB(fbcon);
+out:
 return pixmap;
 }
 #endif
-- 
2.16.2

___
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: [PATCH xserver] modesetting: Fix page flipping under DRI 3.2.

[Daniel Stone]

On 12 March 2018 at 16:57, Mario Kleiner <mario.kleiner...@gmail.com> wrote:
> The check for "no modifier specified" in drmmode_is_format_supported()
> should check for DRM_FORMAT_MOD_INVALID, not for zero, as zero actually
> means DRM_FORMAT_MOD_LINEAR.

If I had a time machine, that would probably be the first thing I
would change about the modifiers API.

Reviewed-by: Daniel Stone <dani...@collabora.com>

Cheers,
Daniel
___
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: [PATCH xserver] glamor/xwayland: Add depth 30 format mapping for DRI 3.2 as well.

[Daniel Stone]

On 9 March 2018 at 03:58, Mario Kleiner <mario.kleiner...@gmail.com> wrote:
> Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>

Reviewed-by: Daniel Stone <dani...@collabora.com>
___
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: [PATCH xserver] glamor: Restore glamor_fd_from_pixmap and glamor_pixmap_from_fd

[Daniel Stone]

Hi Michel,

On 6 March 2018 at 09:53, Michel Dänzer <mic...@daenzer.net> wrote:
> They're part of the 1.20 RC1 ABI, and actually used by external drivers.
> Also, requiring drivers which don't support the new functionality in
> DRI3 1.2 to switch to the new interfaces seems unreasonable.

Thanks for this, and apologies: I'd only checked the DRI3 interface
and missed the Glamor ABI change.

> +_X_EXPORT PixmapPtr
> +glamor_pixmap_from_fd(ScreenPtr screen,
> +  int fd,
> +  CARD16 width,
> +  CARD16 height,
> +  CARD16 stride, CARD8 depth, CARD8 bpp)
> +{
> +PixmapPtr pixmap;
> +Bool ret;
> +
> +pixmap = screen->CreatePixmap(screen, 0, 0, depth, 0);
> +
> +ret = glamor_back_pixmap_from_fd(pixmap, fd, width, height,
> + stride, depth, bpp);
> +
> +if (ret == FALSE) {
> +screen->DestroyPixmap(pixmap);
> +return NULL;
> +}
> +return pixmap;
> +}

Any reason to not make this just 'return
glamor_pixmap_from_fds(screen, 1, , width, height, , &{0},
depth, bpp, DRM_FORMAT_MOD_INVALID)'? Regardless, this is:
Reviewed-by: Daniel Stone <dani...@collabora.com>

Cheers,
Daniel
___
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: [PATCH xserver] xkb: XkbSetMap on the lastSlave needs to change the master

[Daniel Stone]

Hi,

On 3 March 2018 at 01:41, Samir Benmendil <m...@rmz.io> wrote:
> The layout needs to be set on the master too if the layout is changed on
> the device that was last used by the master.

I have a vague recollection that not doing this was a deliberate
choice, but in hindsight, it was also a bad choice.

Acked-by: Daniel Stone <dani...@collabora.com>

Cheers,
Daniel
___
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: [PATCH v8 00/14] DRI3 multi-plane and modifier support

[Daniel Stone]

Hi,

On 28 February 2018 at 01:19, Daniel Stone <dani...@collabora.com> wrote:
> The major change is that the DRI3 protocol version has been bumped from
> 1.1 to 1.2, as there was previously a dri3proto-1.1 release, only
> carrying a 1.0 protocol version. We bump the version to avoid this,
> jumping straight from protocol version 1.0 to 1.2.

Wrong protocol.

Present needed to be bumped to 1.2, and DRI3 should stay at 1.1. I've
made the changes locally.

Cheers,
Daniel
___
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 xorgproto v8 01/14] dri3: Add modifier/multi-plane requests, bump to v1.2

[Daniel Stone]

From: Louis-Francis Ratté-Boulianne <l...@collabora.com>

DRI3 version 1.2 adds support for explicit format modifiers,
including multi-planar buffers.

Signed-off-by: Daniel Stone <dani...@collabora.com>
Signed-off-by: Louis-Francis Ratté-Boulianne <l...@collabora.com>
---
 dri3proto.pc.in|   2 +-
 dri3proto.txt  | 319 +++--
 include/X11/extensions/dri3proto.h |  86 +-
 meson.build|   2 +-
 4 files changed, 396 insertions(+), 13 deletions(-)

diff --git a/dri3proto.pc.in b/dri3proto.pc.in
index 6d81d07..e42d60e 100644
--- a/dri3proto.pc.in
+++ b/dri3proto.pc.in
@@ -5,5 +5,5 @@ includedir=@includedir@
  
 Name: DRI3Proto
 Description: DRI3 extension headers
-Version: 1.0
+Version: 1.2
 Cflags: -I${includedir}
diff --git a/dri3proto.txt b/dri3proto.txt
index dac11d3..94322e7 100644
--- a/dri3proto.txt
+++ b/dri3proto.txt
@@ -1,16 +1,22 @@
  The DRI3 Extension
-Version 1.0
-  2013-6-4
-  
+Version 1.2
+ 2018-02-28
+
Keith Packard
  kei...@keithp.com
  Intel Corporation
 
+       Daniel Stone
+  dani...@collabora.com
+Collabora
+
+
 1. Introduction
 
 The DRI3 extension provides mechanisms to translate between direct
 rendered buffers and X pixmaps. When combined with the Present extension,
-a complete direct rendering solution for OpenGL is provided.
+a complete direct rendering solution for hardware-accelerated devices
+such as GPUs is provided.
 
 The direct rendered buffers are passed across the protocol via
 standard POSIX file descriptor passing mechanisms. On Linux, these
@@ -25,8 +31,9 @@ which can be used to serialize access to shared render 
buffers.
 Eric Anholt <e...@anholt.net>
 Dave Airlie <airl...@redhat.com>
 Kristian Høgsberg <k...@bitplanet.net>
-James Jones <jano...@nvidia.com>
+James Jones <jajo...@nvidia.com>
 Arthur Huillet <arthur.huil...@free.fr>
+Louis-Francis Ratté-Boulianne <l...@collabora.com>
 
 ❄ ❄ ❄  ❄  ❄ ❄ ❄ 
 
@@ -117,9 +124,10 @@ The name of this extension is "DRI3"
Errors: Alloc, Drawable, IDChoice, Value, Match
 
Creates a pixmap for the direct rendering object associated
-   with 'buffer'. Changes to pixmap will be visible in that
-   direct rendered object and changes to the direct rendered
-   object will be visible in the pixmap.
+   with 'buffer' and the screen associated with 'drawable'.
+   Changes to pixmap will be visible in that direct rendered
+   object and changes to the direct rendered object will be
+   visible in the pixmap.
 
'size' specifies the total size of the buffer bytes. 'width',
'height' describe the geometry (in pixels) of the underlying
@@ -137,6 +145,9 @@ The name of this extension is "DRI3"
If depth or bpp are not supported by the screen, a Value error
is returned.
 
+   For information on synchronization of buffer access between
+   the client and the X server, please see section 12.
+
 ┌───
 DRI3BufferFromPixmap
pixmap: PIXMAP
@@ -167,6 +178,9 @@ The name of this extension is "DRI3"
If buffer cannot be used with the screen associated with
drawable, a Match error is returned.
 
+   For information on synchronization of buffer access between
+   the client and the X server, please see section 12.
+
 ┌───
 DRI3FenceFromFD
drawable: DRAWABLE
@@ -182,6 +196,9 @@ The name of this extension is "DRI3"
Details about the mechanism used with this file descriptor are
outside the scope of the DRI3 extension.
 
+   For information on synchronization of buffer access between
+   the client and the X server, please see section 12.
+
 ┌───
 DRI3FDFromFence
drawable: DRAWABLE
@@ -199,8 +216,163 @@ The name of this extension is "DRI3"
associated with a direct rendering device that 'fence' can
work with, otherwise a Match error results.
 
+   For information on synchronization of buffer access between
+   the client and the X server, please see section 12.
 
-❄ ❄ ❄  ❄  ❄ ❄ ❄ 
+┌───
+DRI3GetSupportedModifiers
+   window: WINDOW
+   depth: CARD8
+   bpp: CARD8
+  ▶
+   num_window_modifiers: CARD32
+   num_screen_modifiers: CARD32
+   window_modifiers: ListOfCARD64
+   screen_modifiers: ListOfCARD64
+└───
+   Errors: Window, Match
+
+   Return supported DRM FourCC modifiers for the specified
+   'window'.
+
+   The first list of 'window_modifiers' contains a set of
+   modi

[PATCH xserver v8 08/14] modesetting: Get supported formats/modifiers for scanout

[Daniel Stone]

From: Louis-Francis Ratté-Boulianne <l...@collabora.com>

Retrieve IN_FORMATS property from the plane. It gives the
allowed formats and modifiers for BO allocation.

Signed-off-by: Louis-Francis Ratté-Boulianne <l...@collabora.com>
Reviewed-by: Daniel Stone <dani...@collabora.com>
---
 configure.ac |   4 +
 hw/xfree86/drivers/modesetting/drmmode_display.c | 114 ++-
 hw/xfree86/drivers/modesetting/drmmode_display.h |   9 ++
 include/dix-config.h.in  |   3 +
 include/meson.build  |   2 +
 5 files changed, 128 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 46662867f..283d8e20c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2112,6 +2112,10 @@ if test "x$GLAMOR" = xyes; then
PKG_CHECK_EXISTS(libdrm >= 2.4.74,
 [AC_DEFINE(GLAMOR_HAS_DRM_NAME_FROM_FD_2, 1, [Have 
GLAMOR_HAS_DRM_NAME_FROM_FD_2])],
 [])
+
+   PKG_CHECK_EXISTS(libdrm >= 2.4.83,
+[AC_DEFINE(GLAMOR_HAS_DRM_MODIFIERS, 1, [Have 
GLAMOR_HAS_DRM_MODIFIERS])],
+[])
 fi
 AM_CONDITIONAL([GLAMOR_EGL], [test "x$GBM" = xyes])
 
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 3e3613a98..7af805da2 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -56,6 +56,23 @@ static Bool drmmode_xf86crtc_resize(ScrnInfoPtr scrn, int 
width, int height);
 static PixmapPtr drmmode_create_pixmap_header(ScreenPtr pScreen, int width, 
int height,
   int depth, int bitsPerPixel, int 
devKind,
   void *pPixData);
+
+#ifdef GLAMOR_HAS_DRM_MODIFIERS
+
+static inline uint32_t *
+formats_ptr(struct drm_format_modifier_blob *blob)
+{
+return (uint32_t *)(((char *)blob) + blob->formats_offset);
+}
+
+static inline struct drm_format_modifier *
+modifiers_ptr(struct drm_format_modifier_blob *blob)
+{
+return (struct drm_format_modifier *)(((char *)blob) + 
blob->modifiers_offset);
+}
+
+#endif
+
 static Bool
 drmmode_zaphod_string_matches(ScrnInfoPtr scrn, const char *s, char 
*output_name)
 {
@@ -1532,15 +1549,76 @@ is_plane_assigned(ScrnInfoPtr scrn, int plane_id)
 return FALSE;
 }
 
+#ifdef GLAMOR_HAS_DRM_MODIFIERS
+/**
+ * Populates the formats array, and the modifiers of each format for a 
drm_plane.
+ */
+static Bool
+populate_format_modifiers(xf86CrtcPtr crtc, const drmModePlane *kplane,
+  uint32_t blob_id)
+{
+drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
+drmmode_ptr drmmode = drmmode_crtc->drmmode;
+unsigned i, j;
+drmModePropertyBlobRes *blob;
+struct drm_format_modifier_blob *fmt_mod_blob;
+uint32_t *blob_formats;
+struct drm_format_modifier *blob_modifiers;
+
+blob = drmModeGetPropertyBlob(drmmode->fd, blob_id);
+if (!blob)
+return FALSE;
+
+fmt_mod_blob = blob->data;
+blob_formats = formats_ptr(fmt_mod_blob);
+blob_modifiers = modifiers_ptr(fmt_mod_blob);
+
+assert(drmmode_crtc->num_formats == fmt_mod_blob->count_formats);
+
+for (i = 0; i < fmt_mod_blob->count_formats; i++) {
+uint32_t num_modifiers = 0;
+uint64_t *modifiers = NULL;
+uint64_t *tmp;
+
+for (j = 0; j < fmt_mod_blob->count_modifiers; j++) {
+struct drm_format_modifier *mod = _modifiers[j];
+
+if ((i < mod->offset) || (i > mod->offset + 63))
+continue;
+if (!(mod->formats & (1 << (i - mod->offset
+continue;
+
+num_modifiers++;
+tmp = realloc(modifiers, num_modifiers * sizeof(modifiers[0]));
+if (!tmp) {
+free(modifiers);
+drmModeFreePropertyBlob(blob);
+return FALSE;
+}
+modifiers = tmp;
+modifiers[num_modifiers - 1] = mod->modifier;
+}
+
+drmmode_crtc->formats[i].format = blob_formats[i];
+drmmode_crtc->formats[i].modifiers = modifiers;
+drmmode_crtc->formats[i].num_modifiers = num_modifiers;
+}
+
+drmModeFreePropertyBlob(blob);
+
+return TRUE;
+}
+#endif
+
 static void
 drmmode_crtc_create_planes(xf86CrtcPtr crtc, int num)
 {
 drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
 drmmode_ptr drmmode = drmmode_crtc->drmmode;
 drmModePlaneRes *kplane_res;
-drmModePlane *kplane;
+drmModePlane *kplane, *best_kplane = NULL;
 drmModeObjectProperties *props;
-uint32_t i, type;
+uint32_t i, type, blob_id;
 int current_crtc, best_plane = 0;
 
 static drmmode_prop_enum_info_rec plane_type_enu

[PATCH xserver v8 11/14] glamor: Implement PixmapFromBuffers and BuffersFromPixmap

[Daniel Stone]

From: Louis-Francis Ratté-Boulianne <l...@collabora.com>

It relies on GBM >= 17.1.0 where we can import BO with multiple
planes and a format modifier (GBM_BO_IMPORT_FD_MODIFIER).

v2: Properly free fds in Xwayland

Signed-off-by: Louis-Francis Ratté-Boulianne <l...@collabora.com>
Reviewed-by: Daniel Stone <dani...@collabora.com>
---
 configure.ac  |   4 +
 glamor/glamor.c   |  37 ---
 glamor/glamor.h   |  65 +++--
 glamor/glamor_egl.c   | 136 ++
 glamor/glamor_egl.h   |   1 +
 glamor/glamor_egl_ext.h   |  65 +
 glamor/glamor_egl_stubs.c |  16 ++-
 hw/xwayland/.gitignore|   2 +
 hw/xwayland/Makefile.am   |  10 +-
 hw/xwayland/meson.build   |   5 +-
 hw/xwayland/xwayland-glamor.c | 219 --
 hw/xwayland/xwayland.c|   6 +-
 hw/xwayland/xwayland.h|  10 +-
 include/dix-config.h.in   |   3 +
 include/meson.build   |   2 +
 15 files changed, 461 insertions(+), 120 deletions(-)
 create mode 100644 glamor/glamor_egl_ext.h

diff --git a/configure.ac b/configure.ac
index 283d8e20c..392511541 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2100,6 +2100,10 @@ if test "x$GLAMOR" = xyes; then
[AC_DEFINE(GLAMOR_HAS_GBM_LINEAR, 1, [Have 
GBM_BO_USE_LINEAR])], [],
[#include 
 #include ])
+   dnl 17.1.0 is required for gbm_bo_create_with_modifiers
+   PKG_CHECK_EXISTS(gbm >= 17.1.0,
+[AC_DEFINE(GBM_BO_WITH_MODIFIERS, 1, [Have 
gbm_bo_create_with_modifiers])],
+[])
else
if test "x$XORG" = xyes; then
AC_MSG_ERROR([Glamor for Xorg requires $LIBGBM])
diff --git a/glamor/glamor.c b/glamor/glamor.c
index d61e27563..c890d0ce0 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -32,6 +32,7 @@
  */
 
 #include 
+#include 
 
 #include "glamor_priv.h"
 #include "mipict.h"
@@ -793,8 +794,9 @@ glamor_supports_pixmap_import_export(ScreenPtr screen)
 }
 
 _X_EXPORT int
-glamor_fd_from_pixmap(ScreenPtr screen,
-  PixmapPtr pixmap, CARD16 *stride, CARD32 *size)
+glamor_fds_from_pixmap(ScreenPtr screen, PixmapPtr pixmap, int *fds,
+   uint32_t *strides, uint32_t *offsets,
+   uint64_t *modifier)
 {
 glamor_pixmap_private *pixmap_priv = glamor_get_pixmap_private(pixmap);
 glamor_screen_private *glamor_priv =
@@ -808,10 +810,9 @@ glamor_fd_from_pixmap(ScreenPtr screen,
 if (!glamor_pixmap_ensure_fbo(pixmap, pixmap->drawable.depth == 30 ?
   GL_RGB10_A2 : GL_RGBA, 0))
 return -1;
-return glamor_egl_dri3_fd_name_from_tex(screen,
-pixmap,
-pixmap_priv->fbo->tex,
-FALSE, stride, size);
+return glamor_egl_fds_from_pixmap(screen, pixmap, fds,
+  strides, offsets,
+  modifier);
 default:
 break;
 }
@@ -824,6 +825,9 @@ glamor_shareable_fd_from_pixmap(ScreenPtr screen,
 {
 unsigned orig_usage_hint = pixmap->usage_hint;
 int ret;
+int fds[4];
+uint32_t strides[4], offsets[4];
+uint64_t modifier;
 
 /*
  * The actual difference between a sharable and non sharable buffer
@@ -832,7 +836,20 @@ glamor_shareable_fd_from_pixmap(ScreenPtr screen,
  * 2 of those calls are also exported API, so we cannot just add a flag.
  */
 pixmap->usage_hint = CREATE_PIXMAP_USAGE_SHARED;
-ret = glamor_fd_from_pixmap(screen, pixmap, stride, size);
+ret = glamor_fds_from_pixmap(screen, pixmap, fds, strides, offsets,
+ );
+
+/* Pixmaps with multi-planes/modifier are not shareable */
+if (ret > 1) {
+while (ret > 0)
+close(fds[--ret]);
+return -1;
+}
+
+ret = fds[0];
+*stride = strides[0];
+*size = pixmap->drawable.height * *stride;
+
 pixmap->usage_hint = orig_usage_hint;
 
 return ret;
@@ -849,10 +866,8 @@ glamor_name_from_pixmap(PixmapPtr pixmap, CARD16 *stride, 
CARD32 *size)
 if (!glamor_pixmap_ensure_fbo(pixmap, pixmap->drawable.depth == 30 ?
   GL_RGB10_A2 : GL_RGBA, 0))
 return -1;
-return glamor_egl_dri3_fd_name_from_tex(pixmap->drawable.pScreen,
-pixmap,
-pixmap_priv->fbo->tex,
-TRUE, stride, size);
+return glamor_egl_fd_name_from_pixmap(pixma

[PATCH xserver v8 10/14] modesetting: Check if buffer format is supported when flipping

[Daniel Stone]

From: Louis-Francis Ratté-Boulianne <l...@collabora.com>

Add support for 'check_flip2' so that the present core can know
why it is impossible to flip in that scenario. The core can then
let know the client that the buffer format/modifier is suboptimal.

v2: No longer need to implement 'check_flip'

Signed-off-by: Louis-Francis Ratté-Boulianne <l...@collabora.com>
Reviewed-by: Daniel Stone <dani...@collabora.com>
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 42 
 hw/xfree86/drivers/modesetting/drmmode_display.h |  2 ++
 hw/xfree86/drivers/modesetting/present.c | 30 ++---
 3 files changed, 70 insertions(+), 4 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index bfde3fabf..785849ef9 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -73,6 +73,48 @@ modifiers_ptr(struct drm_format_modifier_blob *blob)
 
 #endif
 
+Bool
+drmmode_is_format_supported(ScrnInfoPtr scrn, uint32_t format, uint64_t 
modifier)
+{
+xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
+int c, i, j;
+
+for (c = 0; c < xf86_config->num_crtc; c++) {
+xf86CrtcPtr crtc = xf86_config->crtc[c];
+drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
+Bool found = FALSE;
+
+if (!crtc->enabled)
+continue;
+
+for (i = 0; i < drmmode_crtc->num_formats; i++) {
+drmmode_format_ptr iter = _crtc->formats[i];
+
+if (iter->format != format)
+continue;
+
+if (modifier == 0) {
+found = TRUE;
+break;
+}
+
+for (j = 0; j < iter->num_modifiers; j++) {
+if (iter->modifiers[j] == modifier) {
+found = TRUE;
+break;
+}
+}
+
+break;
+}
+
+if (!found)
+return FALSE;
+}
+
+return TRUE;
+}
+
 #ifdef GBM_BO_WITH_MODIFIERS
 static uint32_t
 get_modifiers_set(ScrnInfoPtr scrn, uint32_t format, uint64_t **modifiers,
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.h 
b/hw/xfree86/drivers/modesetting/drmmode_display.h
index 75e4b8499..607fe8179 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.h
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.h
@@ -241,6 +241,8 @@ extern DevPrivateKeyRec msPixmapPrivateKeyRec;
 
 #define msGetPixmapPriv(drmmode, p) 
((msPixmapPrivPtr)dixGetPrivateAddr(&(p)->devPrivates, 
&(drmmode)->pixmapPrivateKeyRec))
 
+Bool drmmode_is_format_supported(ScrnInfoPtr scrn, uint32_t format,
+ uint64_t modifier);
 int drmmode_bo_import(drmmode_ptr drmmode, drmmode_bo *bo,
   uint32_t *fb_id);
 int drmmode_bo_destroy(drmmode_ptr drmmode, drmmode_bo *bo);
diff --git a/hw/xfree86/drivers/modesetting/present.c 
b/hw/xfree86/drivers/modesetting/present.c
index 4a01d19ea..71ef2f7f1 100644
--- a/hw/xfree86/drivers/modesetting/present.c
+++ b/hw/xfree86/drivers/modesetting/present.c
@@ -214,7 +214,8 @@ static Bool
 ms_present_check_flip(RRCrtcPtr crtc,
   WindowPtr window,
   PixmapPtr pixmap,
-  Bool sync_flip)
+  Bool sync_flip,
+  PresentFlipReason *reason)
 {
 ScreenPtr screen = window->drawable.pScreen;
 ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
@@ -222,6 +223,9 @@ ms_present_check_flip(RRCrtcPtr crtc,
 xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(scrn);
 int num_crtcs_on = 0;
 int i;
+#ifdef GLAMOR_HAS_DRM_MODIFIERS
+struct gbm_bo *gbm;
+#endif
 
 if (!ms->drmmode.pageflip)
 return FALSE;
@@ -252,6 +256,23 @@ ms_present_check_flip(RRCrtcPtr crtc,
 pixmap->devKind != drmmode_bo_get_pitch(>drmmode.front_bo))
 return FALSE;
 
+#ifdef GLAMOR_HAS_DRM_MODIFIERS
+/* Check if buffer format/modifier is supported by all active CRTCs */
+gbm = glamor_gbm_bo_from_pixmap(screen, pixmap);
+if (gbm) {
+uint32_t format;
+uint64_t modifier;
+
+format = gbm_bo_get_format(gbm);
+modifier = gbm_bo_get_modifier(gbm);
+if (!drmmode_is_format_supported(scrn, format, modifier)) {
+if (reason)
+*reason = PRESENT_FLIP_REASON_BUFFER_FORMAT;
+return FALSE;
+}
+}
+#endif
+
 /* Make sure there's a bo we can get to */
 /* XXX: actually do this.  also...is it sufficient?
  * if (!glamor_get_pixmap_private(pixmap))
@@ -280,7 +301,7 @@ ms_present_flip(RRCrtcPtr crtc,
 Bool ret;
 struct ms_present_vblank_event *event;
 
-if (!ms_present_check_flip(crtc, screen->root, pixmap, sync_flip))
+if (!ms_present_check_flip(crtc, screen->

[PATCH xserver v8 09/14] modesetting: Create scanout buffers using supported modifiers

[Daniel Stone]

From: Louis-Francis Ratté-Boulianne <l...@collabora.com>

Use most optimal buffer format (e.g. tiled/compressed) available
for scanout.

v2: Don't use multi-plane modifier to create scanout buffer

v3: Add flag to retrieve modifiers set from enabled CRTCs only

v4: Fix uses when GBM/EGL driver doesn't support modifiers

Signed-off-by: Louis-Francis Ratté-Boulianne <l...@collabora.com>
Reviewed-by: Daniel Stone <dani...@collabora.com>
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 90 +++-
 1 file changed, 87 insertions(+), 3 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 7af805da2..6fa22da56 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -73,6 +73,68 @@ modifiers_ptr(struct drm_format_modifier_blob *blob)
 
 #endif
 
+#ifdef GBM_BO_WITH_MODIFIERS
+static uint32_t
+get_modifiers_set(ScrnInfoPtr scrn, uint32_t format, uint64_t **modifiers,
+  Bool enabled_crtc_only, Bool exclude_multiplane)
+{
+xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
+modesettingPtr ms = modesettingPTR(scrn);
+drmmode_ptr drmmode = >drmmode;
+int c, i, j, k, count_modifiers = 0;
+uint64_t *tmp, *ret = NULL;
+
+*modifiers = NULL;
+for (c = 0; c < xf86_config->num_crtc; c++) {
+xf86CrtcPtr crtc = xf86_config->crtc[c];
+drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
+
+if (enabled_crtc_only && !crtc->enabled)
+continue;
+
+for (i = 0; i < drmmode_crtc->num_formats; i++) {
+drmmode_format_ptr iter = _crtc->formats[i];
+
+if (iter->format != format)
+continue;
+
+for (j = 0; j < iter->num_modifiers; j++) {
+Bool found = FALSE;
+
+   /* Don't choose multi-plane formats for our screen pixmap.
+* These will get used with frontbuffer rendering, which will
+* lead to worse-than-tearing with multi-plane formats, as the
+* primary and auxiliary planes go out of sync. */
+   if (exclude_multiplane &&
+gbm_device_get_format_modifier_plane_count(drmmode->gbm,
+   format,
+   
iter->modifiers[j]) > 1) {
+continue;
+}
+
+for (k = 0; k < count_modifiers; k++) {
+if (iter->modifiers[j] == ret[k])
+found = TRUE;
+}
+if (!found) {
+count_modifiers++;
+tmp = realloc(ret, count_modifiers * sizeof(uint64_t));
+if (!tmp) {
+free(ret);
+return 0;
+}
+ret = tmp;
+ret[count_modifiers - 1] = iter->modifiers[j];
+}
+}
+}
+}
+
+*modifiers = ret;
+return count_modifiers;
+}
+#endif
+
 static Bool
 drmmode_zaphod_string_matches(ScrnInfoPtr scrn, const char *s, char 
*output_name)
 {
@@ -593,14 +655,36 @@ static Bool
 drmmode_create_bo(drmmode_ptr drmmode, drmmode_bo *bo,
   unsigned width, unsigned height, unsigned bpp)
 {
+uint32_t format;
+
+if (drmmode->scrn->depth == 30)
+format = GBM_FORMAT_ARGB2101010;
+else
+format = GBM_FORMAT_ARGB;
+
 bo->width = width;
 bo->height = height;
 
 #ifdef GLAMOR_HAS_GBM
 if (drmmode->glamor) {
-bo->gbm = gbm_bo_create(drmmode->gbm, width, height,
-drmmode->scrn->depth == 30 ?
-GBM_FORMAT_ARGB2101010 : GBM_FORMAT_ARGB,
+#ifdef GBM_BO_WITH_MODIFIERS
+uint32_t num_modifiers;
+uint64_t *modifiers = NULL;
+
+num_modifiers = get_modifiers_set(drmmode->scrn, format, ,
+  FALSE, TRUE);
+if (num_modifiers > 0 &&
+!(num_modifiers == 1 && modifiers[0] == DRM_FORMAT_MOD_INVALID)) {
+bo->gbm = gbm_bo_create_with_modifiers(drmmode->gbm, width, height,
+   format, modifiers,
+   num_modifiers);
+free(modifiers);
+if (bo->gbm)
+return TRUE;
+}
+#endif
+
+bo->gbm = gbm_bo_create(drmmode->gbm, width, height, format,
 GBM_BO_USE_RENDERING | GBM_BO_USE_SCANOUT);
 return bo->gbm != NULL;
 }
-- 
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

[PATCH xserver v8 14/14] dri3: Enable DRI3 version 1.2

[Daniel Stone]

From: Louis-Francis Ratté-Boulianne <l...@collabora.com>

Enable DRI3 v1.2 now that all functions have been implemented and
that there is at least one backend implementing the driver hooks
(modesetting/glamor).

Signed-off-by: Louis-Francis Ratté-Boulianne <l...@collabora.com>
Reviewed-by: Daniel Stone <dani...@collabora.com>
---
 include/protocol-versions.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/protocol-versions.h b/include/protocol-versions.h
index 39cd2e909..7cab7cd5b 100644
--- a/include/protocol-versions.h
+++ b/include/protocol-versions.h
@@ -48,7 +48,7 @@
 
 /* DRI3 */
 #define SERVER_DRI3_MAJOR_VERSION   1
-#define SERVER_DRI3_MINOR_VERSION   0
+#define SERVER_DRI3_MINOR_VERSION   2
 
 /* DMX */
 #define SERVER_DMX_MAJOR_VERSION   2
-- 
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