Re: Xwayland on demand (Re: [PATCH xwayland 3/3] xwayland: Handle the case of windows being realized before redirection)

[Jasper St. Pierre]

Hi,

Catching up on this thread. It's possible I missed something here, but
here's my two cents.

Right now, the Wayland compositor sets up a "dummy" socket for the X11
display. When a client connects, it launches Xwayland on-demand. I assume
this socket handoff is done similar to the systemd approach, where FDs are
inherited into execution context and their names passed by some convention
like LISTEN_FDS.

Until Xwayland adds the socket to its own loop, the client is paused
anyway. So there are no race conditions here -- the race condition only
happens once Xwayland adds the socket. What if we had a special Wayland
event like "add_listen_fd", using Wayland's FD passing, which would add a
new FD to the listen loop of Xorg. With this, we can create a three-stage
initialization process: 1. Create a special "setup" FD, pass it to
add_listen_fd. 2. Run gnome-settings-daemon, xrdb, on this "setup" FD. 3.
After initialization settles, we then pass the client-activated socket
through "add_listen_fd", and the client will finish the handshake process.

The implementation difficulty here is passing the special setup FD to
clients -- we would have to modify Xlib to allow connecting to an X11
socket by FD (using something like xcb_connect_to_fd), and we would have to
ensure that this all inherits to children correctly if
gnome-settings-daemon needs to launch clients during setup (I think glib
forces O_CLOEXEC before spawning children now -- oops). But FD passing for
initialization is already "the right way" to do things in a systemd world,
so it's probably something investing in.

A quick and dirty prototype of this that wouldn't require FD passing could
simply use DISPLAY=:99 as the "setup display".

Thoughts?

On Thu, Jan 17, 2019 at 3:41 AM Carlos Garnacho  wrote:

> Hi Pekka,
>
> On Thu, Jan 17, 2019 at 10:04 AM Pekka Paalanen 
> wrote:
> >
> > On Thu, 17 Jan 2019 09:47:05 +0100
> > Olivier Fourdan  wrote:
> >
> > > Hi,
> > >
> > > On Thu, Jan 17, 2019 at 9:23 AM Pekka Paalanen 
> wrote:
> > > >
> > > For xrdb specifically, actually, the X11 resources are stored in a
> > > couple of properties on the root window ("RESOURCE_MANAGER" and
> > > "SCREEN_RESOURCES") so Xwayland /could/ set those on init, it's more
> > > the whole logic of merging resources from different files, optionally
> > > invoking a C preprocessor, etc. that would be painful in Xwayland
> > > IMHO.
> > >
> > > So if there was a way to (re)use xrdb to send the resources string to
> > > stdout instead of setting the property itself, Xwayland could possibly
> > > get values to set the properties and do that on startup before any X11
> > > client had a chance to connect.
> > >
> > > Maybe that would be simplereasier than having side-channels or
> > > interlocking in place at startup?
> >
> > Hi Olivier,
> >
> > maybe, but that is again a solution to just one specific issue, while I
> > believe there is a whole category of issues like this. The XWM init is
> > another.
> >
> > If someone starts a X11 window manager as the very first X11 client,
> > could that break the whole Wayland compositor's XWM thing completely?
> > Do we want to protect against that?
>
> In this concrete case, the compositor might also shot Xwayland down if
> it fails to acquire the WM selection.
>
> >
> > Is it worth to solve the whole category at once? I don't know.
>
> Maybe belonging in the category is Xsettings management, esp. those
> that affect UI. It might be visually jarring if the client gets to
> display with different theme/icons than the ones it'll eventually get.
> Again not sure how much of a practical problem this is, accounting
> that toolkits should be good about wayland support, and the outliers
> are probably not concerned about Xsettings.
>
> Anyhow, saying "what a compositor may want to run before launching a
> x11 client is compositor-dependent" doesn't help give any shape to the
> issue :).
>
> Cheers,
>   Carlos
>
> >
> >
> > Thanks,
> > pq
> ___
> 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



-- 
  Jasper
___
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: WebKit failing to find GLXFBConfig, confusion around fbconfigs + swrast

[Jasper St. Pierre]

On Mon, Aug 27, 2018 at 1:07 AM Daniel Drake  wrote:

> Hi,
>
> I'm looking at a strange issue which has taken me across WebKit,
> glvnd, mesa and X, and has left me somewhat confused regarding if I've
> found any real bugs here, or just expected behaviour (my graphics
> knowledge doesn't go far beyond the basics).
>
> The issue:
> Under xserver-1.18 + mesa-18.1, on Intel GeminiLake, the
> Webkit-powered GNOME online accounts UI shows a blank window (instead
> of the web service login UI). The logs show a webkit crash at the same
> time, because it doesn't handle a GLXBadFBConfig X error.
>
> On the Webkit side, it is failing to find an appropriate GLXFBConfig
> that corresponds to the X visual of the window, which is using a depth
> 32 RGBA visual. It then ends up passing a NULL config to
> glXCreateContextAttribsARB() which results in an error.
>
> Inspecting the available visuals and GLXFBConfigs with glxinfo, I
> observe that there is only one visual with depth 32 (the one being
> used here), but there isn't even a single GLXFBConfig with depth 32.
>
> Looking on the X server side, I observe the active code that first
> deals with the fbconfigs list is glxdriswrast.c __glXDRIscreenProbe,
> which is calling into mesa's driSWRastCreateNewScreen() and getting
> the available fbconfigs from there.
>
> I then spotted a log message:
>   (EE) modeset(0): [DRI2] No driver mapping found for PCI device 0x8086 /
> 0x3184
>
> and then I find hw/xfree86/dri2/pci_ids/i965_pci_ids.h, which (on this
> old X) is missing GeminiLake PCI IDs, so I add it there. Now I have my
> depth 32 fbconfig with the right visual assigned and webkit works.
>
>
> Questions:
>
> 1. What should webkit be doing in event of it not being to find a
> GLXFBConfig that corresponds to the X visual of it's window?
>
>
> 2. Why is swrast coming into the picture? Is swrast being used for
> rendering?
>
> I was surprised to see that appear in the traces. I had assumed that
> with a new enough mesa, I would be avoiding software rendering
> codepaths.
>
> I don't think it's using swrast for rendering because I feel like I
> would have noticed corresponding slow performance, also even before my
> changes glxinfo says:
>
>   direct rendering: Yes
>   Extended renderer info (GLX_MESA_query_renderer):
> Vendor: Intel Open Source Technology Center (0x8086)
> Device: Mesa DRI Intel(R) UHD Graphics 605 (Geminilake)  (0x3184)
> Version: 18.1.6
> Accelerated: yes
>
> If swrast is not being used for rendering, why is it being used to
> determine what the available fbconfigs are? Is that a bug?
>
>
> 3. Should swrast offer a depth 32 GLXFBConfig?
>
> If I were on a setup that really uses swrast for rendering (e.g. if
> mesa doesn't provide an accelerated graphics driver), I assume this
> webkit crash would be hit there too, due to not having a depth 32
> fbconfig.
>
> Should it have one?
>
> I didn't investigate in detail, but it looks like mesa's
> dri_fill_in_modes() (perhaps via its calls down to
> llvmpipe_is_format_supported()) declares that depth 32 is not
> supported in the swrast codepath.
>
>
> 4. Why is there still a list of PCI IDs in the X server?
>
> I was under the impression that these days, rendering stuff has been
> handed off to mesa, and display stuff has been handed off to KMS. Both
> the kernel and mesa have corresponding drivers for those functions
> (and their own lists of PCI IDs).
>
> I was then surprised to see the X server also maintaining a list of
> PCI IDs and it having a significant effect on which codepaths are
> followed.
>
>
> Thanks for any clarifications!
>

So this is a fun question and took me a day or two of random spelunking.
Let's start with the last question, since it gives us a good starting
point: why are the PCI IDs necessary?

The answer is "DRI2 needs to figure out the driver to load if the user
doesn't pass it into DRI2Connect".
https://gitlab.freedesktop.org/xorg/xserver/blob/master/hw/xfree86/dri2/dri2.c#L1440

Let's now ask and answer two more follow-up questions: 1. Why is the server
using DRI2, 2. Why does the server need the driver name, and 3. Why doesn't
mesa pass the driver name along?

My best guess for why DRI2 is being used is that xf86-video-intel turns it
off by default, because ickle didn't like the implicit synchronization that
DRI3 had and refused to fix some bugs in it. So if you load
xf86-video-intel, unless you configure it to turn on DRI3, you get DRI2.
Yay.

As for why mesa doesn't pass the driver name along, the answer just is that
it doesn't. Maybe it should?
https://github.com/mesa3d/mesa/blob/bd963f84302adb563136712c371023f15dadbea7/src/glx/dri2_glx.c#L1196

DRI3 works a bit differently -- an FD is passed to the X server by mesa,
and the DDX figures out how to interpret that FD. The full flow in rootless
X is that logind picks an FD, passes that to the X server, and then the DDX
driver (likely -modesetting) calls drmGetDeviceNameFromFd2, and all the
logic is 

Re: A question about XCompositeRedirectSubwindows

[Jasper St. Pierre]

On Wed, Jun 20, 2018 at 8:19 AM Adam Jackson  wrote:

> On Tue, 2018-06-19 at 17:35 -0700, Jasper St. Pierre wrote:
>
> > First off, there's a super high latency cost here.
>
> There is a latency cost, but I think it's worth being honest about it.
> I'm on whatever iteration of the Dell XPS laptop was a Skylake, and:
>
> 200 trep @   0.0131 msec ( 76100.0/sec): QueryPointer
>
> You get 70k round trips a second? That... might actually be enough. You
> have sixty frames, so that's like a thousand per frame, and then the
> USB interrupt rate is only like 1kHz so you only need to service 16
> per frame anyway. Okay, this is a 3GHz machine; at 300MHz - assuming it
> scales linearly - your round trip budget is a hundred per frame, you'd
> still have like 80% of the CPU left.
>

I remember trying to do this at one point for gnome-shell's magnifier mode,
and found some severe performance issues. I never dug deeper, because of
the other issues I saw, but I was seeing actual latency with my eyes. It's
probably just a bug, though.


> > Second, actually filling in the correct event is unobvious and
> > tricky, especially when dealing with XInput2. It would require
> > building the equivalent of an X server inside your CM to send.
>
> It turns out there does already exist a library of code that implements
> these state transitions the way an X server would. It is: the X server.
> One of my "never got enough around to" projects was making the server
> code sufficiently library-like that you could embed an X server the way
> libssh means you can embed an ssh server. It's honestly not far off.
>

Yep. GDK's client-side windows also attempts to emulate an X server given
that GdkWindow is modeled after an X window, or at least it was in the GTK+
2.0 era. It would be wonderful to have the code to Enter/Leave correctly
and all that fun stuff in a library for people to reuse, so that they can
set up a window tree and "be as X11".

To be clear about the full list of issues I encountered, at a basic level:

* Active grabs obviously break your COW trick. GTK+ menus broke. I hacked
around this by taking an active grab on my COW from start and letting the
fallback path of GTK+ take over.
* XSendEvent skips passive grabs, which some clients did not like. I forget
which app was using passive grabs a lot, but when it saw a ButtonPress
event it then tried to call XChangeActivePointerGrab to convert it into an
active grab, and when that failed it crashed. I forget if I fixed this.
* Clients can call XQueryPointer when receiving a FocusNotify to figure out
where their pointer is. Most of the time, this isn't an issue, but the
regression is that if you hover over a button in GTK+, Alt-Tab away, then
Alt-Tab back, it would highlight the wrong part of the window. I fixed this
by sending a fake MotionNotify after focusing the client which mostly got
it on the right track.
* Similarly, some application set MotionNotifyHint and then called
GetMotionEvents. I was unable to fix this.
* Java's AWT filters out some synthetic events for some unimaginable reason.

Also, similar problems, but now do it all over again for XI2. And touch
input. I never even bothered to start with that.


> > To be honest, this problem was one of the original problems that
> > Wayland tried to solve. In the Wayland architecture, the display
> > server and compositing manager are combined into a single process,
>
> This is not an essential feature of the Wayland model. The compositing
> manager could, like an X compositing manager, be a separate client,
> interacting with an essentially separate set of protocols, and the
> display server would merely be a broker of handles to surfaces, some of
> which happen to be bound to hardware that displays pixels.
>
> No extant wayland server _does_ this, as far as I know. But it has some
> appeal.
>

Yeah, but this is a compositor implementation detail. Similarly, an X11
window manager could choose to talk some private protocol to other
components and help manage windows. gnome-shell certainly does, even on X11.

The distinction is that it is *possible* for a compositor to be in charge
of the event tree and sending events to clients. It is not possible, at a
general sense, to do the same in X11 without severe hacks. Maybe if the
RedirectCoordinate and TransformCoordinate parts of Composite were finished
and implemented, things would be different today. I don't have any context
into why those never got in, though.


> - ajax
>


-- 
  Jasper
___
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: A question about XCompositeRedirectSubwindows

[Jasper St. Pierre]

On Tue, Jun 19, 2018 at 2:23 PM Egil Möller 
wrote:

> Oups, sorry for my reply-to-you-only, that was a mistake.
>
> So my problem with letting events "fall through" to the window is that I
> plan to do zoom (hence the OpenGL), both in and out, and would like to have
> events working even in a zoomed state... The window manager idea I'd like
> to build is one that extends the multiple virtual workspaces metaphor into
> an infinite desktop that you can zoom and pan as you like, and paste a
> window onto at any size at any zoom level... It might be a bit hard as a
> first project this deep into X stuff, but it's something I've wanted to
> build for a long while. So, what are the reasons synthesizing events will
> fail (and how will they fail)?
>

First off, there's a super high latency cost here. Second, actually filling
in the correct event is unobvious and tricky, especially when dealing with
XInput2. It would require building the equivalent of an X server inside
your CM to send. It would probably not be too much work for anything that
doesn't use too many server-side subwindows and just treats the window as a
single surface, so it mght be good enough for most cases, but I'd be
sketchy. And most apps that don't use server-side windows will be the ones
using XI2. Third, input grabs will override your COW, so anything that uses
a pointer grab will see bizarre behavior. Fourth, synthesized events are
specially marked, and some clients might throw out events with the
synthesized flag set.

To be honest, this problem was one of the original problems that Wayland
tried to solve. In the Wayland architecture, the display server and
compositing manager are combined into a single process, and the compositor
has full control over sending events to surfaces. It might be easier to
hack up a Wayland compositor to get it to do what you want.


> Hehe, that is the impression I got from plowing through the specs and code
> too.. It would kind of be useful to get to talk to one of those people
> about how things are "supposed to work".
>

A lot of those people are on this list. Or, if not here, on the
wayland-devel list. I'm not one of them, but I feel I've worked on enough
X-related things to understand how the system is put together.


> Thanks! I think I might need it :P
>
>
> On 19. juni 2018 16:52, Jasper St. Pierre wrote:
>
> Hi,
>
> (Re-adding xorg-devel. Please make sure to keep the list CC'd in the
> future)
>
> It is possible for a window to set "no background color", in which case
> the existing window contents are used for the pixmap. xclock likely sets no
> background color. You can check an individual window's properties with
> xwininfo.
>
> Redrawing the screen every frame isn't a bad idea for a simple compositor
> to get started. For a more fancy, complete redraw loop, you can track when
> windows get drawn to with with the Damage extension, and schedule a repaint
> when that happens. Bonus points if you use the damage rectangles to be more
> accurate with your redraw. Also, helpful hint that windows get their
> backing pixmaps thrown away when resized -- you need to pay attention to
> ConfigureNotify and regrab the backing pixmap with
> XCompositeNameWindowPixmap, and that whole jazz.
>
> I don't recommend synthesizing input events -- a lot of things are likely
> to break or just not work well. Set an empty input shape on the COW, and
> make sure to draw windows where they want to be. Pay attention to
> MotionNotify events from windows that are moving.
>
> I'm unaware of any beginner-level documentation or tutorials. The number
> of people that have written a compositing manager from scratch can be
> counted on one hand, and a lot of them had a hand in designing the
> architecture to begin with.
> https://magcius.github.io/xplain/article/composite.html has some ideas of
> the broader concepts, but none of the details.
>
> Good luck.
>
> On Tue, Jun 19, 2018 at 2:01 AM Egil Möller 
> wrote:
>
>> Hi!
>>
>> Thanks for answering a noob question :) Ha! That's so not documented (in
>> an obvious way)! I was assuming that I could get the initial window
>> content, as already drawn (obviously clipped to whatever is visible on
>> screen) directly... So why does xclock "work" then? I just haven't gotten
>> around to event handling yet, wanted to learn the drawing/copying methods
>> themselves first...
>>
>> Two follow up questions:
>>
>>   * How should I redraw the screen? As often as I can, or waiting for
>> some event for all redirected windows (which event)?
>>   * Can I capture input events (key, mouse) for the overlay window and
>> then somehow synthesize them for whatever window / subwindow my window
>

Re: A question about XCompositeRedirectSubwindows

[Jasper St. Pierre]

Hi,

(Re-adding xorg-devel. Please make sure to keep the list CC'd in the future)

It is possible for a window to set "no background color", in which case the
existing window contents are used for the pixmap. xclock likely sets no
background color. You can check an individual window's properties with
xwininfo.

Redrawing the screen every frame isn't a bad idea for a simple compositor
to get started. For a more fancy, complete redraw loop, you can track when
windows get drawn to with with the Damage extension, and schedule a repaint
when that happens. Bonus points if you use the damage rectangles to be more
accurate with your redraw. Also, helpful hint that windows get their
backing pixmaps thrown away when resized -- you need to pay attention to
ConfigureNotify and regrab the backing pixmap with
XCompositeNameWindowPixmap, and that whole jazz.

I don't recommend synthesizing input events -- a lot of things are likely
to break or just not work well. Set an empty input shape on the COW, and
make sure to draw windows where they want to be. Pay attention to
MotionNotify events from windows that are moving.

I'm unaware of any beginner-level documentation or tutorials. The number of
people that have written a compositing manager from scratch can be counted
on one hand, and a lot of them had a hand in designing the architecture to
begin with. https://magcius.github.io/xplain/article/composite.html has
some ideas of the broader concepts, but none of the details.

Good luck.

On Tue, Jun 19, 2018 at 2:01 AM Egil Möller 
wrote:

> Hi!
>
> Thanks for answering a noob question :) Ha! That's so not documented (in
> an obvious way)! I was assuming that I could get the initial window
> content, as already drawn (obviously clipped to whatever is visible on
> screen) directly... So why does xclock "work" then? I just haven't gotten
> around to event handling yet, wanted to learn the drawing/copying methods
> themselves first...
>
> Two follow up questions:
>
>   * How should I redraw the screen? As often as I can, or waiting for some
> event for all redirected windows (which event)?
>   * Can I capture input events (key, mouse) for the overlay window and
> then somehow synthesize them for whatever window / subwindow my window
> manager thinks it has drawn in that position? Some docs I read sounded like
> this is impossible, and you should turn of input for the overlay, and
> position the real window underneath in a "strategic position"...
>
> Also, is there any good documentation and/or tutorials around this
> anywhere?
>
> /Egil
>
> On 19. juni 2018 08:42, Jasper St. Pierre wrote:
>
> Hi,
>
> What you're seeing here is a fun little side effect of composite. As you
> might be aware, unredirected X windows don't have any backing storage
> beyond the front buffer -- the full window contents are not really there.
> That means that when the X server first goes to redirect these windows, it
> decides that it should let the window paint again, and sends the window an
> Expose event to let it know it should repaint. A side effect of this is
> that the X server redraws the background for the window. This is the
> semantics for what an Expose event means -- an area that is "Exposed" is
> the background color until the client paints over it.
>
> The client will eventually paint its window contents, but since your CM
> does not appear to have a frame loop, and it only paints once, you do not
> see the updated frame contents.
>
> On Sun, Jun 17, 2018 at 1:28 PM Egil Möller 
> wrote:
>
>> Hi!
>>
>> I'm trying to write a new compositing window manager, and finding the
>> documentation for the API:s I need quite spread out.
>>
>> The particular problem I'm having right now is that copying some windows
>> (xclock) using
>> XCompositeRedirectSubwindows and e.g. XRenderComposite works fine, while
>> other windows (xterm, xlock) leaves me we a square with only their
>> background color. This seems to be true for both XRenderComposite and
>> glXBindTexImageEXT. Any ideas what's different between them, and what I
>> need to do differently?
>>
>> My code is here: https://github.com/redhog/InfiniteGlass
>> (main code is in wm.c; running "make" ahould give you an Xephyr nested X
>> session that shows the problem).
>>
>> Thanks in advance,
>>
>> Egil Möller
>>
>>
>>
>> ___
>> 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
>
>
>
> --
>   Jasper
>
>
>

-- 
  Jasper
___
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: A question about XCompositeRedirectSubwindows

[Jasper St. Pierre]

Hi,

What you're seeing here is a fun little side effect of composite. As you
might be aware, unredirected X windows don't have any backing storage
beyond the front buffer -- the full window contents are not really there.
That means that when the X server first goes to redirect these windows, it
decides that it should let the window paint again, and sends the window an
Expose event to let it know it should repaint. A side effect of this is
that the X server redraws the background for the window. This is the
semantics for what an Expose event means -- an area that is "Exposed" is
the background color until the client paints over it.

The client will eventually paint its window contents, but since your CM
does not appear to have a frame loop, and it only paints once, you do not
see the updated frame contents.

On Sun, Jun 17, 2018 at 1:28 PM Egil Möller 
wrote:

> Hi!
>
> I'm trying to write a new compositing window manager, and finding the
> documentation for the API:s I need quite spread out.
>
> The particular problem I'm having right now is that copying some windows
> (xclock) using
> XCompositeRedirectSubwindows and e.g. XRenderComposite works fine, while
> other windows (xterm, xlock) leaves me we a square with only their
> background color. This seems to be true for both XRenderComposite and
> glXBindTexImageEXT. Any ideas what's different between them, and what I
> need to do differently?
>
> My code is here: https://github.com/redhog/InfiniteGlass
> (main code is in wm.c; running "make" ahould give you an Xephyr nested X
> session that shows the problem).
>
> Thanks in advance,
>
> Egil Möller
>
>
>
> ___
> 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



-- 
  Jasper
___
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: Making Composite better for interactive apps

[Jasper St. Pierre]

How is this different from unredirection? mutter / gnome-shell currently
doesn't unredirect windowed windows, but there's no reason it couldn't --
it just needs to be able to handle the case where it's unredirecting the
client window rather than the parent frame window.

On Fri, Feb 2, 2018 at 5:43 PM, Keith Packard  wrote:

>
> I visited Valve recently and sat down with Pierre-Loup to hash out what
> it would take to improve X compositing behavior with interactive
> applications. I've written those up on my blog here:
>
> https://keithp.com/blogs/CompositeAcceleration/
>
> If you've got questions or comments, I'd love to see them here on the
> mailing list.
>
> --
> -keith
>
> ___
> 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
>



-- 
  Jasper
___
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: NotifyGrab

[Jasper St. Pierre]

Hi,

Selecting for XI2 events will disable core input events from being sent to
your client. This is to prevent XI2-enabled clients from getting duplicate
events and not knowing which to filter out. You need to select for
XI_FocusIn / XI_FocusOut events instead of using the core input events.


On Thu, Nov 23, 2017 at 8:37 AM, Samuel Thibault <
samuel.thiba...@ens-lyon.org> wrote:

> Hello,
>
> I'm working on making compiz use XI2 to get more fine-grain hold
> on keypresses.  I'm however getting an issue: I do not always get
> NotifyGrab FocusIn events from the root window when a client calls
>
> XGrabKeyboard (mydisplay, mywindow, True, GrabModeAsync, GrabModeAsync,
> CurrentTime);
>
> , which prevents from properly respecting grabbing.
>
>
> Unfortunately, I didn't manage to reproduce the issue with a simpler X
> root event listener: runnning
>
> XSelectInput(mydisplay, DefaultRootWindow(mydisplay), FocusChangeMask);
>
> does properly bring focus out/in NotifyGrab events, but these events
> don't get to Compiz. I also tried to listen on the window itself with
> the same result: my simple event listener gets the event, but Compiz
> does not.
>
> Oddly enough, this seems to depend on the application: kvm / virtualbox
> grabbing have the issue, but vncviewer grabbing doesn't have the issue.
>
> Reading https://tronche.com/gui/x/xlib/input/XGrabKeyboard.html tells me
> that there should always be FocusIn / FocusOut events being generated,
> so I don't immediately see where to look for in the differences between
> by simple listener and Compiz.
>
> Could there be some undocumented cases where such events are not
> generated?  Any idea where I could look in the X server to check what is
> happening?
>
> Samuel
> ___
> 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




-- 
  Jasper
___
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: weird Xwayland and compositor deadlock issue [WAS: [PATCH xserver v2] xwayland: handle EAGAIN and EINTR gracefully]

[Jasper St. Pierre]

Hi,

Based on my reading of the spec, writing an ICCCM-compliant WM *requires*
blocking, since the behavior of an UnmapNotify depends on the attributes of
a window. We cannot process any X11 events while we are retrieving the
attributes of a mapped window inside MapRequest.

If we want to modify the X11 protocol to provide non-blocking events to
provide e.g. attributes in MapRequest, values in PropertyNotify, and shapes
in ShapeNotify (the three major cases of required blocking right now), I'd
be for it.

Focus management is extremely complex and subtle. Reading back on the
history:

https://bugzilla.gnome.org/show_bug.cgi?id=701017
https://bugzilla.gnome.org/show_bug.cgi?id=720558

The first patch was overly complex -- the XChangeProperty to bump the
serial could have simply been a XNoOp to bump the serial while under server
grab. :) We could even make that cleanup now. But it would be a minor
simplification.

Daniel suggested that timestamps *should* be on the same timebase.
Currently, they are not. X11 server timestamps are
CLOCK_MONOTONIC_COARSE-based and are calculated at delivery time, evdev
timestamps are CLOCK_MONOTONIC-based and are calculated at input time. This
is why there are several focus management bugs that happen when you replace
meta_display_get_current_time_roundtrip() with a clock_gettime().

We need to fix this, otherwise we can never properly synchronize X11 event
streams and Wayland event streams. But Xorg calls GetCurrentTimeMillis()
literally everywhere and compares against that instead of using evdev's own
timestamps, and I doubt we can fix that without breaking multiple, multiple
clients.

The only thing I can think of for that is, again, the Wayland-in-X11
solution: an X11 extension that delivers the timestamp with every response
and event from the server so we don't block on a PropertyChange for it.


On Wed, Sep 14, 2016 at 12:56 AM, Pekka Paalanen 
wrote:

> On Tue, 13 Sep 2016 12:04:14 -0400 (EDT)
> Olivier Fourdan  wrote:
>
> > Hi Pekka,
> >
> > - Original Message -
> > > Hi Olivier,
> > >
> > > I don't have any solution for you. The interactions between the Wayland
> > > compositor and Xwayland are known to be very easily deadlockable IIRC.
> I
> > > believe the only thing you can do is ensure no such case can ever
> > > occur, which is very painful. That is, never do a blocking roundtrip at
> > > least from one side.
> > >
> > > Have the recent modifications caused a significant increase of Wayland
> > > requests from Xwayland? If Xwayland needs to send an amount of data
> > > bigger than bufferable, *any* blocking roundtrip via X11 from the
> > > Wayland compositor is prone to deadlock. It will be waiting for a reply
> > > via X11, while Xwayland is blocked on flushing, since the Wayland
> > > compositor is not consuming requests.
> > >
> > > It can also trivially happen if both sides do a blocking roundtrip at
> > > the same time. Or just a wait for an event.
> > >
> > > Either server needs to be able to return to its main loop to process
> the
> > > protocol stream it is the server for. Preferably both, I think.
> >
> > Unfortunately, any XSync (like, for example, called in
> > gdk_error_trap_pop() in gdk) will issue a blocking roundtrip, and
> > window managers tend to do that quite a lot (some more than others)
> > so I don't think we can easily chaneg that in window managers to
> > avoid blocking rountrips on X11 side.
> >
> > > You could check how Weston's XWM works. I highly suspect that after
> > > Xwayland launch it avoids doing any blocking roundtrips via X11.
> >
> > Yet sometimes some X calls are blocking, e.g. XShapeGetRectangles()
> > or even XGetWindowAttributes() which is invoked by mutter each time
> > the a new window is mapped. mutter still uses Xlib and not xcb.
> >
> > > I'd assume Xwayland also tries to avoid blocking on Wayland events,
> > > but if nothing else, I believe Mesa via GLAMOR may block on
> > > wl_buffer.release events... or maybe not if GLAMOR is smart with its
> > > throttling. Anyway, since your flush is hitting EAGAIN, that doesn't
> > > seem to be the cause.
> > >
> > > I wonder if making wl_display_flush() block immediately like in your
> > > patch could be replaced by adding the wl_display fd to the main poll
> > > loop, so that it would get flushed ASAP but still service X11
> > > requests in the mean time? It does run the risk of overflowing the
> > > Wayland send buffer in Xwayland. Any way to prioritize the Wayland
> > > compositor's X11 connection in Xwayland?
> >
> > If I don't make EAGAIN a FatalError() and wait for the Wayland
> > display file descriptor to become writable again, Xwayland eventually
> > dies with another error "(EE) request could not be marshaled: can't
> > send file descriptor" from libwayland directly (in
> > copy_fds_to_connection()).
>
> Hi,
>
> summarizing from #wayland irc between Olivier and Daniel: the proper
> solution is indeed to never do 

Re: ARMSOC X11 plugin issues

[Jasper St. Pierre]

ARMSOC isn't a well-written driver, basically. Is there a reason
you're not using modesetting if it works better for you?

On Thu, Mar 31, 2016 at 1:54 AM, Maxime Ripard
 wrote:
> On Wed, Mar 23, 2016 at 10:17:05PM +0100, Maxime Ripard wrote:
>> Hi David, Marico,
>>
>> I've been developping a DRM/KMS driver for the Allwinner SoCs[1], with
>> an additional patch to allocate GPU buffers [2]. Since those SoCs also use
>> a Mali GPU, using the armsoc X11 plugin seemed like a logical choice.
>>
>> I added support for the driver based on the 1.4 plugin [3], and
>> started using it, which turned out pretty well, we get something
>> displayed, GLES works, good.
>>
>> However, after testing it for a while, the first thing we noticed was
>> that some (large) buffer allocations would start to fail. Indeed, the
>> plugin seems to do a lot of rather small (and for most temporary ?)
>> buffer allocations, which eventually depletes the reserved memory
>> pool. The allocation then fails, and the application crashes.
>>
>> Then, we noticed (using xfce4, on debian jessie) that the systray
>> icons were not displayed for some reason. There's also some game
>> (alex4 [4]), that starts, runs, but the window content remains black
>> (but it remains interactive, audio plays and if we take a screenshot,
>> the content is on the image, but the screen remains black).
>>
>> The weird thing about it is that when using the X generic modesetting
>> plugin, everything starts to work. It seems to be allocating only one
>> buffer per plane, so we never have the memory allocation
>> failures. Which raises my first question: why is the armsoc plugin
>> behaving differently there?
>>
>> Then the graphics issues we were seeing are not there anymore, which
>> seems to indicate that it's related to the plugin. I'm a bit oblivious
>> to how X works exactly, and how applications interacts with it, but on
>> the ioctl side, nothing really stands out. Let me know if you need any
>> more tests or logs or anything.
>
> Anyone ?
>
> Thanks,
> Maxime
>
>
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.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



-- 
  Jasper
___
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: Proposal for Anti-Keystroke Fingerprinting at the Display Server Level

[Jasper St. Pierre]

I think this should be done at the application level. If an
application is running, it has many other ways to fingerprint your
computer, including listing the files in your homedir, checking cpuid,
MAC address, etc. The issue here is that there is an application
platform that runs untrusted user code, which has tried hard to get
rid of fingerprinting identifiers (however, I believe window size,
installed fonts and GPU rendering differences remain the primary
fingerprint identifiers at this point for ad networks). The randomness
in the event stream should be done in the air-gap between the trusted
code and the untrusted code.

Too many other use cases require completely accurate timing, and I'm
not convinced a generic solution for defeating trusted code is a good
idea. Perhaps a library can be shared between implementations.

On Thu, Mar 24, 2016 at 6:18 AM,   wrote:
> On 2016-03-24 12:45, Pekka Paalanen wrote:
>>
>>
>> Hi,
>>
>> that's interesting. Sounds like you are looking for volunteers to
>> implement what you want, right?
>
>
> Yes please. Unfortunately I don't know C or have the skill to code something
> like this myself.
>
>>
>> I skimmed through [3], and I got the impression that what the software
>> does is to round key press and release times to the nearest multiple of
>> 50ms or something along those lines.
>>
>> I can immediately see one problem with that approach: key repeat.
>>
>> Key repeat is based on a timer. On Wayland, that timer is currently in
>> the application, not in the kernel nor even in the display server. If
>> you skew the timings, you may screw up the repeats. For the record, it
>> seems the default repeat on Weston is 40 Hz, which means 25 ms period.
>> Rounding to nearest 50 ms sounds like a pretty big difference.
>
>
> I originally proposed this on the QEMU/Libvirt lists and we reached the
> conclusion that the Display-server or kernel is the best place for this to
> benefit as many people as possible.
>
> Someone replied with ideas about what an implementation would look like and
> he covers some of the problems you bring up:
> https://lists.nongnu.org/archive/html/qemu-discuss/2016-03/msg00024.html
>
>>
>> Another issue are gamers, who are going to hate you for messing up
>> their key timings, so this system must be user-controlled.
>
>
> Yes having this as an option people can change for specific usecases is the
> way to go. Per app or a global setting - which ever possible could work
> here.
>
>>
>> I suppose there is also a practical issue of synchronizing key events
>> to other input events. E.g. if you want to ctrl+click something, you
>> have to synchronize multiple input event streams under the same timing
>> fudging system to avoid the case where sometimes the key is not
>> accounted for when clicking.
>>
>> All that makes me wonder if the kernel is a sensible place for this.
>> For a machine specifically built to be more secure at the expence of
>> usability by ignoring all the above issues, then perhaps.
>>
>
> I posted on lkml but no one seems to show interest and within a few hours my
> message is already buried.
>
>>
>> Thanks,
>> pq
>>
>>>
>>> [1]
>>>
>>> http://arstechnica.com/security/2015/07/how-the-way-you-type-can-shatter-anonymity-even-on-tor/
>>>
>>> [2] http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=7358795
>>>
>>> [3] https://archive.is/vCvWb
>>>
>>> [4]
>>>
>>> https://www.lightbluetouchpaper.org/2015/07/30/double-bill-password-hashing-competition-keyboardprivacy/#comment-1288166
>>>
>>> [5] https://trac.torproject.org/projects/tor/ticket/16110
>>>
>>> [6] https://trac.torproject.org/projects/tor/ticket/1517
>>>
>>>
>>> ___
>>> 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
>>
>>
>> ___
>> wayland-devel mailing list
>> wayland-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
> ___
> 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



-- 
  Jasper
___
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:makedepend] Use do { ... } while(0) idiom to make debug() macro safer

[Jasper St. Pierre]

"Safe multi-line macros" have been suggested before, and turned down.
The C extension that gcc supports is statement expressions:
https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html

On Sat, Mar 12, 2016 at 11:15 AM, walter harms  wrote:
>
>
> Am 12.03.2016 19:43, schrieb Matt Turner:
>> On Sat, Mar 12, 2016 at 10:24 AM, walter harms  wrote:
>>>
>>>
>>> Am 12.03.2016 19:15, schrieb Alan Coopersmith:
 Cleans up several -Wempty-body warnings from gcc 5.3

 Signed-off-by: Alan Coopersmith 
 ---
  def.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/def.h b/def.h
 index 1930cde..59670a9 100644
 --- a/def.h
 +++ b/def.h
 @@ -82,9 +82,9 @@ extern int  _debugmask;
   * 3 show #include SYMBOL
   * 4-6   unused
   */
 -#define debug(level,arg) { if (_debugmask & (1 << level)) warning arg; }
 +#define debug(level,arg) do { if (_debugmask & (1 << level)) warning arg; 
 } while(0)
  #else
 -#define  debug(level,arg) /**/
 +#define  debug(level,arg) do { /**/ } while (0)
  #endif /* DEBUG */

  typedef  unsigned char boolean;
>>>
>>>
>>>  #definedebug(level,arg)   while(0)
>>>
>>> should be sufficient (not tested)
>>
>> Maybe, but that sure looks strange to my eye, while the do { ... }
>> while(0) pattern is well recognized.
>
> for me other way around :)
>
> never mind, both are a noop, someone could propose this as C extension ,)
>
> re,
>  wh
> ___
> 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



-- 
  Jasper
___
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] modesetting: allow switching from software to hardware cursors.

[Jasper St. Pierre]

Can you give an example of when drmSetCursor2 would fail sometimes but
not always, enough to switch back and forth actively?

I'm not a huge fan of the patch because now errors could cause really
bizarre double-cursor, or no-cursor flickering, since there is no
guarantee that the swapover happens in the same frame.

We sort-of tried this in Weston for something else (we rendered
certain windows in overlays) and had to turn it off and go to always
SW because of the obnoxious flickering, at least until atomic landed.

On Sat, Mar 12, 2016 at 3:54 AM, Michael Thayer
 wrote:
> Hello,
>
> I would just like to politely draw attention to this again.  I would assume
> from the silence that the people who might review it don't think it is a
> completely wrong thing (that would not take long to say) but don't have the
> spare cycles to take a closer look.  Any idea when someone might have twenty
> minutes to review it?
>
> Regards,
>
> Michael
>
>
> On 06.03.2016 12:56, Michael Thayer wrote:
>>
>> Currently if modesetting ever fails to set a hardware cursor it will
>> switch
>> to using a software cursor and never go back.  Change this to try a
>> hardware
>> cursor first every time a new one is set.  This is needed because hardware
>> may be able to handle some cursors in harware and others not, or virtual
>> hardware may be able to handle hardware cursors at some times and not
>> others.
>>
>> Signed-off-by: Michael Thayer 
>> ---
>> Made the commit message more verbose on Emil's request.
>>
>>   hw/xfree86/drivers/modesetting/drmmode_display.c | 47
>> ++--
>>   1 file changed, 20 insertions(+), 27 deletions(-)
>>
>> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
>> b/hw/xfree86/drivers/modesetting/drmmode_display.c
>> index 0d34ca1..36c3093 100644
>> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
>> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
>> @@ -485,44 +485,36 @@ drmmode_set_cursor_position(xf86CrtcPtr crtc, int x,
>> int y)
>>   drmModeMoveCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, x,
>> y);
>>   }
>>
>> -static void
>> +static Bool
>>   drmmode_set_cursor(xf86CrtcPtr crtc)
>>   {
>>   drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
>>   drmmode_ptr drmmode = drmmode_crtc->drmmode;
>>   uint32_t handle = drmmode_crtc->cursor_bo->handle;
>>   modesettingPtr ms = modesettingPTR(crtc->scrn);
>> -static Bool use_set_cursor2 = TRUE;
>>   int ret;
>>
>> -if (use_set_cursor2) {
>> -xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
>> -CursorPtr cursor = xf86_config->cursor;
>> -
>> -ret =
>> -drmModeSetCursor2(drmmode->fd,
>> drmmode_crtc->mode_crtc->crtc_id,
>> -  handle, ms->cursor_width,
>> ms->cursor_height,
>> -  cursor->bits->xhot, cursor->bits->yhot);
>> -if (!ret)
>> -return;
>> -if (ret == -EINVAL)
>> -use_set_cursor2 = FALSE;
>> -}
>> +xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
>> +CursorPtr cursor = xf86_config->cursor;
>>
>> -ret = drmModeSetCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
>> handle,
>> -   ms->cursor_width, ms->cursor_height);
>> +ret =
>> +drmModeSetCursor2(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
>> +  handle, ms->cursor_width, ms->cursor_height,
>> +  cursor->bits->xhot, cursor->bits->yhot);
>> +if (!ret)
>> +return TRUE;
>>
>> -if (ret) {
>> -xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
>> -xf86CursorInfoPtr cursor_info = xf86_config->cursor_info;
>> +/* -EINVAL can mean bad cursor parameters or Cursor2 API not
>> supported. */
>> +if (ret == -EINVAL)
>> +ret = drmModeSetCursor(drmmode->fd,
>> drmmode_crtc->mode_crtc->crtc_id,
>> +   handle, ms->cursor_width,
>> ms->cursor_height);
>>
>> -cursor_info->MaxWidth = cursor_info->MaxHeight = 0;
>> -drmmode_crtc->drmmode->sw_cursor = TRUE;
>> -/* fallback to swcursor */
>> -}
>> +if (ret)
>> +return FALSE; /* fallback to swcursor */
>> +return TRUE;
>>   }
>>
>> -static void
>> +static Bool
>>   drmmode_load_cursor_argb(xf86CrtcPtr crtc, CARD32 *image)
>>   {
>>   modesettingPtr ms = modesettingPTR(crtc->scrn);
>> @@ -537,7 +529,8 @@ drmmode_load_cursor_argb(xf86CrtcPtr crtc, CARD32
>> *image)
>>   ptr[i] = image[i];  // cpu_to_le32(image[i]);
>>
>>   if (drmmode_crtc->cursor_up)
>> -drmmode_set_cursor(crtc);
>> +return drmmode_set_cursor(crtc);
>> +return TRUE;
>>   }
>>
>>   static void
>> @@ -799,7 +792,7 @@ static const xf86CrtcFuncsRec drmmode_crtc_funcs = {
>>   .set_cursor_position = 

Re: [PATCH] modesetting: add support for background none.

[Jasper St. Pierre]

As mentioned in the original email, it relies on this series:

https://lists.x.org/archives/xorg-devel/2016-February/048758.html

On Tue, Mar 8, 2016 at 9:41 AM, Adam Jackson  wrote:
> On Wed, 2016-02-10 at 15:45 +1000, Dave Airlie wrote:
>
>> From: Dave Airlie 
>>
>> This adds support using glamor for background None.
>>
>> loosely based off the amdgpu code. relies on the
>> glamor_finish code.
>>
>> Signed-off-by: Dave Airlie 
>
> NAK:
>
>> +void
>> +drmmode_copy_fb(ScrnInfoPtr pScrn, drmmode_ptr drmmode)
>> +{
>> +xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(pScrn);
>> +ScreenPtr pScreen = xf86ScrnToScreen(pScrn);
>> +PixmapPtr src, dst;
>> +int fbcon_id = 0;
>> +GCPtr gc;
>> +int i;
>> +
>> +for (i = 0; i < xf86_config->num_crtc; i++) {
>> +drmmode_crtc_private_ptr drmmode_crtc = 
>> xf86_config->crtc[i]->driver_private;
>> +if (drmmode_crtc->mode_crtc->buffer_id)
>> +fbcon_id = drmmode_crtc->mode_crtc->buffer_id;
>> +}
>> +
>> +if (!fbcon_id)
>> +return;
>> +
>> +if (fbcon_id == drmmode->fb_id) {
>> +/* in some rare case there might be no fbcon and we might already
>> + * be the one with the current fb to avoid a false deadlck in
>> + * kernel ttm code just do nothing as anyway there is nothing
>> + * to do
>> + */
>> +return;
>> +}
>> +
>> +src = create_pixmap_for_fbcon(drmmode, pScrn, fbcon_id);
>> +if (!src)
>> +return;
>> +
>> +dst = pScreen->GetScreenPixmap(pScreen);
>> +
>> +gc = GetScratchGC(pScrn->depth, pScreen);
>> +ValidateGC(>drawable, gc);
>> +
>> +(*gc->ops->CopyArea)(>drawable, >drawable, gc, 0, 0,
>> + pScrn->virtualX, pScrn->virtualY, 0, 0);
>> +
>> +FreeScratchGC(gc);
>> +
>> +glamor_finish(pScreen);
>
> drmmode_display.c: In function 'drmmode_copy_fb':
> drmmode_display.c:377:5: error: implicit declaration of function 
> 'glamor_finish' [-Werror=implicit-function-declaration]
>  glamor_finish(pScreen);
>
> - ajax
> ___
> 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



-- 
  Jasper
___
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: Use drm buffers for cursors if available

[Jasper St. Pierre]

I don't necessarily have an opinion either way, but do note that since
VGEM isn't here yet, this change will break using Xwayland under a
free VM. We should fall back to wl_shm in any case.

On Wed, Feb 10, 2016 at 9:16 AM, Daniel Stone  wrote:
> On 10 February 2016 at 17:08, Kristian Høgsberg  wrote:
>> On Wed, Feb 10, 2016 at 7:39 AM, Emil Velikov  
>> wrote:
>>> On 5 February 2016 at 08:42, Pekka Paalanen  wrote:
>>>
 umm, do we really want to add even more uses of the Mesa-private wl_drm
 protocol outside of Mesa? Though it seems that ship sailed a long time
 ago.

 Should we just bite the bullet, and have Mesa install drm.xml for
 public consumption? Or move drm.xml to wayland-protocols.git?

 I thought all that was a Bad Idea(tm).

>>> If we consider that distributing the protocol for public consumption
>>> is OK, please use wayland-protocols.git. Keeping it in mesa will lead
>>> to nasty circular dependencies.
>>
>> I think we should. It's pretty much the equivalent of dri2proto and
>> it's useful for projects such as libva as well.
>
> Why not a stabliised zlinux_dmabuf instead? The only thing I can
> really say against it is that it lacks FB modifier support, but, well,
> so does wl_drm (and gbm, which means you can't extract multi-plane
> buffers to overlays, or particularly sensibly to
> non-TEXTURE_EXTERNAL_OES GL ...).
>
> 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



-- 
  Jasper
___
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: Use hardware sprite plane as overlay

[Jasper St. Pierre]

I thought XV was simply about color conversion, it didn't handle video
display. I didn't Google it before replying, though.

On Tue, Jan 5, 2016 at 6:23 PM, Michel Dänzer <mic...@daenzer.net> wrote:
> On 30.12.2015 04:52, Jasper St. Pierre wrote:
>> The only currently supported mechanism for using hardware overlays is
>> video planes through VDPAU / VA-API.
>
> And XVideo?
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Enable Glamor EGL with Mali

[Jasper St. Pierre]

Let me copy/paste an internal email I wrote when I was investigating a
similar thing.

===

I've been investigating using the new Glamor acceleration layer for
our Xorg DDX.

For those not familiar with Glamor, basically, it implements X11
drawing primitives on top of OpenGL, so you can use your GPU instead
of your CPU for drawing. It's a pretty significant win over software
rendering, so I started to investigate poking at it.

The first issue I encountered is that Glamor is designed to work
together with desktop GL and GLX. It does have a GLES mode, but I
really had to push hard and patch a bunch of stuff to figure out how
to turn it on. The Mali driver only has EGL and OpenGL ES. So, that's
a patch: http://sprunge.us/TggM

To actually talk to the underlying GL library, Glamor uses a utility
library called Epoxy which tries to wrangle WGL / AGL / GLX / EGL /
OpenGL / OpenGLES / everything.

Unfortunately, Epoxy hardcodes the assumption that if we're building
on Linux, we *must* have a full OpenGL stack. So, yeah, I needed to
patch that as well: http://sprunge.us/JQPi

We require a libGL to build the GLX extension, even though we
shouldn't ever load it in practice, but this is just another bit of
confusion for Epoxy, which might try to load the wrong libGL.

Anyway, after all that, you mess up your build environment and then
give up, and then realize that you messed up.

...

So here's where I'm at now. In order to do rendering to an offscreen
buffer that we can export, Glamor uses the "gbm" backend to EGL, which
allows us to render to a buffer of our choosing. Unfortunately, it
seems that backend isn't turned on in our Mali build.

So now, eglInitialize(); is still failing, even after a long time of
patching. At this point, I think the initial investigation is mostly
complete. I still think that if there's some downtime, I'm going to
pick this back up, since I do believe that it will significantly help
some of the performance issues I've been seeing. Slow application
performance can be traced with `perf top` back to fb's software
rendering.

Future problems:

Glamor requires several EGL extensions. One of those is
surfaceless_context, which I've already hackily (and untested-ly!)
implemented for now in the DDK, but another would be MESA_drm_image,
which will be a lot more tricky to support.

===

If you have a copy of the closed-source Mali DDK source tree, we
should talk offline about implementing this if you want to continue
it. It would be a major win for us.

On Mon, Jan 4, 2016 at 5:07 AM, Erez Schneider  wrote:
> Hello,
>
> I'm trying to enable glamor EGL on a Mali GPU (using mali binary egl/gles
> driver with x11).
> I am building xserver-xorg without GBM support (I had to change the
> galmor_egl.c a bit for it to compile properly, but from looking at it, it
> seems it's not a must to use GBM).
> I am calling eglGetDisplay() and it returns a display struct but when I call
> eglInitialize(), while setting DISPLAY=:0 the xserver just hangs.
>
> Any Idea on how to get this going?
>
> Thanks!
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Use hardware sprite plane as overlay

[Jasper St. Pierre]

Well, the X server shutdown process would have restored the fbcon
console and turned out KD_TEXT, I would have thought. I don't think
you can assume that the front buffer will stay exactly still quite
yet.

It also does mean that all clients that were previously running are
now dead, and you have to restart them. So you can't render to the
primary and sprite planes at the same time.

Again, I would really recommend you use Wayland or another system.

On Fri, Jan 1, 2016 at 6:06 PM, Cao Duc Quan <caoducq...@gmail.com> wrote:
> But I could run it!
> There is a trick for this: first I stop xorg by running this command:
> service xserver-nodm stop
>
> Than I run my tool
> ./modetest_x11 -s 9:XR24 -P 9:1280x720@XR24
>
> After that I start xorg again
> service xserver-nodm start
>
> And it seems xserver start successful. And I have both xserver render to
> primary buffer and modetest render to Sprite Plane
>
> It is a bug in kernel ?
>
> On Fri, Jan 1, 2016 at 5:04 AM, Jasper St. Pierre <jstpie...@mecheye.net>
> wrote:
>>
>> You can't. The only client that is allowed to do modesets, either on
>> planes or on the primary buffer, is the DRM master, which in this case
>> is the Xorg server. It would be much easier and better to use Wayland
>> instead.
>>
>> On Thu, Dec 31, 2015 at 12:16 AM, Cao Duc Quan <caoducq...@gmail.com>
>> wrote:
>> > Thanks Jasper.
>> > I plan to hook to QT embedded to make it use sprite plane buffer.
>> > I could make a tool (customized from modetest.c of libdrm) to render to
>> > sprite plane which are running in xorg.
>> >
>> > Thanks and Happy New Year.
>> > cdq
>> >
>> > On Wed, Dec 30, 2015 at 2:52 AM, Jasper St. Pierre
>> > <jstpie...@mecheye.net>
>> > wrote:
>> >>
>> >> The only currently supported mechanism for using hardware overlays is
>> >> video planes through VDPAU / VA-API.
>> >>
>> >> Xorg does not have any other supported mechanism for using hardware
>> >> overlays. Try looking at Wayland, which can have support for hardware
>> >> planes.
>> >>
>> >> On Fri, Dec 25, 2015 at 8:29 AM, Cao Duc Quan <caoducq...@gmail.com>
>> >> wrote:
>> >> > Dear all,
>> >> > I am studying the Graphics stack in linux.
>> >> > I found that the Intel Baytrail E38xx support 2 pipe display and each
>> >> > pipe
>> >> > has
>> >> > - 1 x primary plane
>> >> > - 2 x sprite plane
>> >> > - 1 x cursor plane
>> >> >
>> >> > Is it possible to use sprite plane as overlay plane which means we
>> >> > can
>> >> > render UI to sprite plane (for example QT could render Widget to
>> >> > sprite
>> >> > plane) ? If so, could any one point me to some a sample code or any
>> >> > documents ?
>> >> >
>> >> > Many Thanks,
>> >> > --
>> >> > Quan Cao
>> >> > 0976574864
>> >> >
>> >> > ___
>> >> > xorg-devel@lists.x.org: X.Org development
>> >> > Archives: http://lists.x.org/archives/xorg-devel
>> >> > Info: http://lists.x.org/mailman/listinfo/xorg-devel
>> >>
>> >>
>> >>
>> >> --
>> >>   Jasper
>> >
>> >
>> >
>> >
>> > --
>> > Quan Cao
>> > 0976574864
>>
>>
>>
>> --
>>   Jasper
>
>
>
>
> --
> Quan Cao
> 0976574864



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Use hardware sprite plane as overlay

[Jasper St. Pierre]

You can't. The only client that is allowed to do modesets, either on
planes or on the primary buffer, is the DRM master, which in this case
is the Xorg server. It would be much easier and better to use Wayland
instead.

On Thu, Dec 31, 2015 at 12:16 AM, Cao Duc Quan <caoducq...@gmail.com> wrote:
> Thanks Jasper.
> I plan to hook to QT embedded to make it use sprite plane buffer.
> I could make a tool (customized from modetest.c of libdrm) to render to
> sprite plane which are running in xorg.
>
> Thanks and Happy New Year.
> cdq
>
> On Wed, Dec 30, 2015 at 2:52 AM, Jasper St. Pierre <jstpie...@mecheye.net>
> wrote:
>>
>> The only currently supported mechanism for using hardware overlays is
>> video planes through VDPAU / VA-API.
>>
>> Xorg does not have any other supported mechanism for using hardware
>> overlays. Try looking at Wayland, which can have support for hardware
>> planes.
>>
>> On Fri, Dec 25, 2015 at 8:29 AM, Cao Duc Quan <caoducq...@gmail.com>
>> wrote:
>> > Dear all,
>> > I am studying the Graphics stack in linux.
>> > I found that the Intel Baytrail E38xx support 2 pipe display and each
>> > pipe
>> > has
>> > - 1 x primary plane
>> > - 2 x sprite plane
>> > - 1 x cursor plane
>> >
>> > Is it possible to use sprite plane as overlay plane which means we can
>> > render UI to sprite plane (for example QT could render Widget to sprite
>> > plane) ? If so, could any one point me to some a sample code or any
>> > documents ?
>> >
>> > Many Thanks,
>> > --
>> > Quan Cao
>> > 0976574864
>> >
>> > ___
>> > xorg-devel@lists.x.org: X.Org development
>> > Archives: http://lists.x.org/archives/xorg-devel
>> > Info: http://lists.x.org/mailman/listinfo/xorg-devel
>>
>>
>>
>> --
>>   Jasper
>
>
>
>
> --
> Quan Cao
> 0976574864



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Use hardware sprite plane as overlay

[Jasper St. Pierre]

The only currently supported mechanism for using hardware overlays is
video planes through VDPAU / VA-API.

Xorg does not have any other supported mechanism for using hardware
overlays. Try looking at Wayland, which can have support for hardware
planes.

On Fri, Dec 25, 2015 at 8:29 AM, Cao Duc Quan  wrote:
> Dear all,
> I am studying the Graphics stack in linux.
> I found that the Intel Baytrail E38xx support 2 pipe display and each pipe
> has
> - 1 x primary plane
> - 2 x sprite plane
> - 1 x cursor plane
>
> Is it possible to use sprite plane as overlay plane which means we can
> render UI to sprite plane (for example QT could render Widget to sprite
> plane) ? If so, could any one point me to some a sample code or any
> documents ?
>
> Many Thanks,
> --
> Quan Cao
> 0976574864
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH] composite: Don't bother copying the pixmap for ForgetGravity windows (v3)

[Jasper St. Pierre]

If a window has ForgetGravity in its bitGravity, that very likely
means it will repaint on the ConfigureNotify / Expose event, and thus
we don't have to copy the old pixmap into the new pixmap, we can simply
leave it blank.

Preventing this copy is super simple to do and a big win on small
devices where these blits can be expensive.

A better approach would be to actually obey BitGravity correctly rather
than assume NorthWestGravity always, but this is a big speedup for the
common case.

v2: Check all subwindows to make sure they are also ForgetGravity
v3: Destroy old pixmap before creating the new one

Cc: Adam Jackson <a...@redhat.com>
Signed-off-by: Jasper St. Pierre <jstpie...@mecheye.net>
---
 composite/compalloc.c | 113 ++
 1 file changed, 67 insertions(+), 46 deletions(-)

diff --git a/composite/compalloc.c b/composite/compalloc.c
index 8daded0..06b54e9 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -526,6 +526,21 @@ compUnredirectOneSubwindow(WindowPtr pParent, WindowPtr 
pWin)
 return Success;
 }
 
+static Bool
+needsPixmapCopy(WindowPtr pWin)
+{
+WindowPtr pChild;
+
+if (pWin->bitGravity != ForgetGravity)
+return TRUE;
+
+for (pChild = pWin->firstChild; pChild; pChild = pChild->nextSib)
+if (needsPixmapCopy(pChild))
+return TRUE;
+
+return FALSE;
+}
+
 static PixmapPtr
 compNewPixmap(WindowPtr pWin, int x, int y, int w, int h)
 {
@@ -542,54 +557,56 @@ compNewPixmap(WindowPtr pWin, int x, int y, int w, int h)
 pPixmap->screen_x = x;
 pPixmap->screen_y = y;
 
-if (pParent->drawable.depth == pWin->drawable.depth) {
-GCPtr pGC = GetScratchGC(pWin->drawable.depth, pScreen);
-
-if (pGC) {
-ChangeGCVal val;
-
-val.val = IncludeInferiors;
-ChangeGC(NullClient, pGC, GCSubwindowMode, );
-ValidateGC(>drawable, pGC);
-(*pGC->ops->CopyArea) (>drawable,
-   >drawable,
-   pGC,
-   x - pParent->drawable.x,
-   y - pParent->drawable.y, w, h, 0, 0);
-FreeScratchGC(pGC);
+if (needsPixmapCopy(pWin)) {
+if (pParent->drawable.depth == pWin->drawable.depth) {
+GCPtr pGC = GetScratchGC(pWin->drawable.depth, pScreen);
+
+if (pGC) {
+ChangeGCVal val;
+
+val.val = IncludeInferiors;
+ChangeGC(NullClient, pGC, GCSubwindowMode, );
+ValidateGC(>drawable, pGC);
+(*pGC->ops->CopyArea) (>drawable,
+   >drawable,
+   pGC,
+   x - pParent->drawable.x,
+   y - pParent->drawable.y, w, h, 0, 0);
+FreeScratchGC(pGC);
+}
 }
-}
-else {
-PictFormatPtr pSrcFormat = PictureWindowFormat(pParent);
-PictFormatPtr pDstFormat = PictureWindowFormat(pWin);
-XID inferiors = IncludeInferiors;
-int error;
-
-PicturePtr pSrcPicture = CreatePicture(None,
-   >drawable,
-   pSrcFormat,
-   CPSubwindowMode,
-   ,
-   serverClient, );
-
-PicturePtr pDstPicture = CreatePicture(None,
-   >drawable,
-   pDstFormat,
-   0, 0,
-   serverClient, );
-
-if (pSrcPicture && pDstPicture) {
-CompositePicture(PictOpSrc,
- pSrcPicture,
- NULL,
- pDstPicture,
- x - pParent->drawable.x,
- y - pParent->drawable.y, 0, 0, 0, 0, w, h);
+else {
+PictFormatPtr pSrcFormat = PictureWindowFormat(pParent);
+PictFormatPtr pDstFormat = PictureWindowFormat(pWin);
+XID inferiors = IncludeInferiors;
+int error;
+
+PicturePtr pSrcPicture = CreatePicture(None,
+   >drawable,
+   pSrcFormat,
+   CPSubwindowMode,
+   ,
+   serverClient, );
+
+PicturePtr pDstPicture = CreatePicture(None,
+  

Re: [PATCH xlib] Add support for a display-specific error handler

[Jasper St. Pierre]

Yes, because Xlib will pick those events up and call its default
handler in its mainloop. As far as I can tell, there's no way to
configure that behavior. Using xcb without the Xlib mainloop is not an
option, because this is a library embedded in another application and
its API takes an Xlib Display* (also because it's a nearly 10,000 line
codebase and porting it to xcb in one giant go is not fun, especially
when xcb code is some of the least fun code to write in the universe).
We currently use a behavior like:

SetErrorHandler();
Request1();
Request2();
Request3();
if (UnsetErrorHandlerAndCheck())
goto error;

UnsetErrorHandlerAndCheck will XSync, and look at any newly incoming
errors, check their serials so that they match up, and if they are
inside those bounds, we return the error to the user and return that
no error happened. Fairly standard trick.

With xcb, I can do:

if (check_request(request_1_checked(), ) {
free(err);
goto error;
}
if (check_request(request_2_checked(), ) {
free(err);
goto error;
}
if (check_request(request_3_checked(), ) {
free(err);
goto error;
}

But this quickly becomes obnoxious (and requires an XSync/wait on
every request) As far as I can tell, I can't pick up *only* error
events, meaning that if during that time I make those requests, there
are other events in the queue, I can't filter through the queue for
any errors that might have happened. If I have any events, I have to
handle all of them.

So that's clearly unusable.

The Display-specific error handler solves my needs here by giving me a
callback to that above model that's locked to that local section that
works well from a library -- this code runs in a different thread, and
we had issues where we overwrite another thread's error handler (in my
case, the two threads were using different Displays, as they should).

On Sun, Nov 15, 2015 at 11:56 PM, Keith Packard <kei...@keithp.com> wrote:
> "Jasper St. Pierre" <jstpie...@mecheye.net> writes:
>
>> Writing error-safe code that uses Xlib is too obnoxious, and using XCB
>> is tedious and not performant, as we can't catch events on a giant
>> stream -- we have to check every operation manually.
>
> You get errors returned in the event stream; is there something fancier
> you'd like from xcb to make it faster?
>
> --
> -keith
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xlib] Add support for a display-specific error handler

[Jasper St. Pierre]

Now do this:

static void Foo()
{
Request1();
Request2();
}

static void Bar()
{
Request1();
Request3();
}

static void Thing(int x)
{
SetErrorHandler();
if (x == 0)
Foo();
else
Bar();
UnsetErrorHandlerAndCheck();
}

We have a similar codepath in our driver and this is where I gave up
and started on the Xlib solution.


On Mon, Nov 16, 2015 at 12:39 PM, Uli Schlachter <psyc...@znc.in> wrote:
> Am 16.11.2015 um 18:06 schrieb Jasper St. Pierre:
> [...]
>> We currently use a behavior like:
>>
>> SetErrorHandler();
>> Request1();
>> Request2();
>> Request3();
>> if (UnsetErrorHandlerAndCheck())
>> goto error;
>>
>> UnsetErrorHandlerAndCheck will XSync, and look at any newly incoming
>> errors, check their serials so that they match up, and if they are
>> inside those bounds, we return the error to the user and return that
>> no error happened. Fairly standard trick.
>>
>> With xcb, I can do:
>>
>> if (check_request(request_1_checked(), ) {
>> free(err);
>> goto error;
>> }
>> if (check_request(request_2_checked(), ) {
>> free(err);
>> goto error;
>> }
>> if (check_request(request_3_checked(), ) {
>> free(err);
>> goto error;
>> }
>>
>> So that's clearly unusable.
>
> Well, why?
>
> How about this version:
>
> xcb_void_cookie_t cookies[3];
>
> cookies[0] = request_1_checked();
> cookies[1] = request_2_checked();
> cookies[2] = request_3_checked();
>
> bool had_error = false;
> for (int i = 0; i < 3; i++) {
>   xcb_generic_error_t *err = xcb_request_check(c, cookies[i]);
>   had_error |= err != NULL;
>   free(NULL);
> }
>
> This only syncs once during the first call to xcb_request_check() and 
> afterwards
> it's done. This even improves parallelism, because you do not have to
> XLockDisplay() to lock out other threads (which also means that "just a range 
> of
> sequence numbers" isn't enough and an array is needed).
>
> You could even generalize this with some helper functions to make it nicer,
> similar to your SetErrorHandler() and UnsetErrorHandlerAndCheck() above.
>
> Uli
>
> [...]
>> The Display-specific error handler solves my needs here by giving me a
>> callback to that above model that's locked to that local section that
>> works well from a library -- this code runs in a different thread, and
>> we had issues where we overwrite another thread's error handler (in my
>> case, the two threads were using different Displays, as they should).
>>
>> On Sun, Nov 15, 2015 at 11:56 PM, Keith Packard <kei...@keithp.com> wrote:
>>> "Jasper St. Pierre" <jstpie...@mecheye.net> writes:
>>>
>>>> Writing error-safe code that uses Xlib is too obnoxious, and using XCB
>>>> is tedious and not performant, as we can't catch events on a giant
>>>> stream -- we have to check every operation manually.
>>>
>>> You get errors returned in the event stream; is there something fancier
>>> you'd like from xcb to make it faster?
>>>
>>> --
>>> -keith
>
> --
> "Every once in a while, declare peace. It confuses the hell out of your 
> enemies"
>  - 79th Rule of Acquisition
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xlib] Add support for a display-specific error handler

[Jasper St. Pierre]

Writing error-safe code that uses Xlib is too obnoxious, and using XCB
is tedious and not performant, as we can't catch events on a giant
stream -- we have to check every operation manually.

In my specific case (writing a GL driver), it would be enough to simply
have a Display-specific error handler, since our driver re-opens the
Display in our own code, but a better approach might be TLS storage for
the global handler.

Signed-off-by: Jasper St. Pierre <jstpie...@mecheye.net>
---
 include/X11/Xlib.h|  4 
 include/X11/Xlibint.h |  3 +++
 src/ErrHndlr.c| 15 +++
 src/XlibInt.c | 12 +++-
 4 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/include/X11/Xlib.h b/include/X11/Xlib.h
index 2bffa76..772e88c 100644
--- a/include/X11/Xlib.h
+++ b/include/X11/Xlib.h
@@ -1849,6 +1849,10 @@ extern XErrorHandler XSetErrorHandler (
 XErrorHandler  /* handler */
 );
 
+extern XErrorHandler XDisplaySetErrorHandler(
+Display*/* display */,
+XErrorHandler   /* handler */
+);
 
 typedef int (*XIOErrorHandler) (/* WARNING, this type not in Xlib spec */
 Display*   /* display */
diff --git a/include/X11/Xlibint.h b/include/X11/Xlibint.h
index 4431559..e05792f 100644
--- a/include/X11/Xlibint.h
+++ b/include/X11/Xlibint.h
@@ -205,6 +205,9 @@ struct _XDisplay
XGenericEventCookie *   /* in */,
XGenericEventCookie *   /* out*/);
void *cookiejar;  /* cookie events returned but not claimed */
+
+   /* display-specific error handler */
+   XErrorHandler err_handler;
 };
 
 #define XAllocIDs(dpy,ids,n) (*(dpy)->idlist_alloc)(dpy,ids,n)
diff --git a/src/ErrHndlr.c b/src/ErrHndlr.c
index 167a68b..a8e1eee 100644
--- a/src/ErrHndlr.c
+++ b/src/ErrHndlr.c
@@ -84,3 +84,18 @@ XSetIOErrorHandler(XIOErrorHandler handler)
 
 return (XIOErrorHandler) oldhandler;
 }
+
+XErrorHandler
+XDisplaySetErrorHandler(Display *dpy, XErrorHandler handler)
+{
+XErrorHandler old_handler;
+#ifdef XTHREADS
+LockDisplay(dpy);
+#endif
+old_handler = dpy->err_handler;
+dpy->err_handler = handler;
+#ifdef XTHREADS
+UnlockDisplay(dpy);
+#endif
+return old_handler;
+}
diff --git a/src/XlibInt.c b/src/XlibInt.c
index 80c1298..d720e7b 100644
--- a/src/XlibInt.c
+++ b/src/XlibInt.c
@@ -1387,6 +1387,16 @@ Bool _XDefaultWireError(Display *display, XErrorEvent 
*he, xError *we)
 return True;
 }
 
+static int
+DispatchDisplayErrorEvent (Display *dpy,
+   XErrorEvent *event)
+{
+if (dpy->err_handler)
+return dpy->err_handler(dpy, event);
+else
+return _XErrorFunction(dpy, event);
+}
+
 /*
  * _XError - upcall internal or user protocol error handler
  */
@@ -1426,7 +1436,7 @@ int _XError (
(*dpy->lock->user_lock_display)(dpy);
UnlockDisplay(dpy);
 #endif
-   rtn_val = (*_XErrorFunction)(dpy, (XErrorEvent *)); /* upcall */
+   rtn_val = DispatchDisplayErrorEvent(dpy, (XErrorEvent *)); /* 
upcall */
 #ifdef XTHREADS
LockDisplay(dpy);
if (dpy->lock)
-- 
2.4.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libXi] Don't use raw serial numbers in XIEvents

[Jasper St. Pierre]

On Sun, Oct 18, 2015 at 7:59 PM, Peter Hutterer
 wrote:
> cookie->serial is an Xlib contoction, provided by _XSetLastRequestRead(). This

I assume this is meant to read "in->sequenceNumber is an Xlib
concoction"? Otherwise, it doesn't make sense.

> serial may be different to the raw serial number from the wire protocol.
> This causes issues when the raw serial is used to e.g. compare the event to
> other non-XI events.
>
> Use the cookie's serial number instead.
>
> https://bugzilla.gnome.org/show_bug.cgi?id=756649
>
> See also https://bugs.freedesktop.org/show_bug.cgi?id=64687
>
> Signed-off-by: Peter Hutterer 
> ---
>  src/XExtInt.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/src/XExtInt.c b/src/XExtInt.c
> index 672d69a..a35fcc6 100644
> --- a/src/XExtInt.c
> +++ b/src/XExtInt.c
> @@ -1521,7 +1521,7 @@ wireToDeviceEvent(xXIDeviceEvent *in, 
> XGenericEventCookie* cookie)
>  out = next_block(_lib, sizeof(XIDeviceEvent));
>  out->display = cookie->display;
>  out->type = in->type;
> -out->serial = in->sequenceNumber;
> +out->serial = cookie->serial;
>  out->extension = in->extension;
>  out->evtype = in->evtype;
>  out->send_event = ((in->type & 0x80) != 0);
> @@ -1794,7 +1794,7 @@ wireToDeviceChangedEvent(xXIDeviceChangedEvent *in, 
> XGenericEventCookie *cookie)
>  cookie->data = out = malloc(sizeof(XIDeviceChangedEvent) + len);
>
>  out->type = in->type;
> -out->serial = in->sequenceNumber;
> +out->serial = cookie->serial;
>  out->display = cookie->display;
>  out->extension = in->extension;
>  out->evtype = in->evtype;
> @@ -1827,7 +1827,7 @@ wireToHierarchyChangedEvent(xXIHierarchyEvent *in, 
> XGenericEventCookie *cookie)
>  out->info   = (XIHierarchyInfo*)[1];
>  out->display= cookie->display;
>  out->type   = in->type;
> -out->serial = in->sequenceNumber;
> +out->serial = cookie->serial;
>  out->extension  = in->extension;
>  out->evtype = in->evtype;
>  out->send_event = ((in->type & 0x80) != 0);
> @@ -1868,7 +1868,7 @@ wireToRawEvent(XExtDisplayInfo *info, xXIRawEvent *in, 
> XGenericEventCookie *cook
>
>  out = next_block(, sizeof(XIRawEvent));
>  out->type   = in->type;
> -out->serial = in->sequenceNumber;
> +out->serial = cookie->serial;
>  out->display= cookie->display;
>  out->extension  = in->extension;
>  out->evtype = in->evtype;
> @@ -1919,7 +1919,7 @@ wireToEnterLeave(xXIEnterEvent *in, XGenericEventCookie 
> *cookie)
>  out->buttons.mask = (unsigned char*)[1];
>
>  out->type   = in->type;
> -out->serial = in->sequenceNumber;
> +out->serial = cookie->serial;
>  out->display= cookie->display;
>  out->extension  = in->extension;
>  out->evtype = in->evtype;
> @@ -1962,7 +1962,7 @@ wireToPropertyEvent(xXIPropertyEvent *in, 
> XGenericEventCookie *cookie)
>  cookie->data = out;
>
>  out->type   = in->type;
> -out->serial = in->sequenceNumber;
> +out->serial = cookie->serial;
>  out->extension  = in->extension;
>  out->evtype = in->evtype;
>  out->send_event = ((in->type & 0x80) != 0);
> @@ -1983,7 +1983,7 @@ wireToTouchOwnershipEvent(xXITouchOwnershipEvent *in,
>  cookie->data = out;
>
>  out->type   = in->type;
> -out->serial = in->sequenceNumber;
> +out->serial = cookie->serial;
>  out->display= cookie->display;
>  out->extension  = in->extension;
>  out->evtype = in->evtype;
> @@ -2011,7 +2011,7 @@ wireToBarrierEvent(xXIBarrierEvent *in, 
> XGenericEventCookie *cookie)
>
>  out->display= cookie->display;
>  out->type   = in->type;
> -out->serial = in->sequenceNumber;
> +out->serial = cookie->serial;
>  out->extension  = in->extension;
>  out->evtype = in->evtype;
>  out->send_event = ((in->type & 0x80) != 0);
> --
> 2.4.3
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH:twm] Add some const.

[Jasper St. Pierre]

Should also mention that it also adds a strdup -- I feel that the code
calling this might conditionally free. Would be nice to double-check
callers.

On Wed, Sep 23, 2015 at 1:58 AM, Thomas Klausner  wrote:
> From: Christos Zoulas 
>
> Signed-off-by: Thomas Klausner 
> ---
>  src/util.c | 4 ++--
>  src/util.h | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/util.c b/src/util.c
> index 4b94051..5e8f0db 100644
> --- a/src/util.c
> +++ b/src/util.c
> @@ -256,11 +256,11 @@ Zoom(Window wf, Window wt)
>   *  \param name  the filename to expand
>   */
>  char *
> -ExpandFilename(char *name)
> +ExpandFilename(const char *name)
>  {
>  char *newname;
>
> -if (name[0] != '~') return name;
> +if (name[0] != '~') return strdup(name);
>
>  newname = malloc (HomeLen + strlen(name) + 2);
>  if (!newname) {
> diff --git a/src/util.h b/src/util.h
> index 7f4527c..4b2d3a8 100644
> --- a/src/util.h
> +++ b/src/util.h
> @@ -64,7 +64,7 @@ in this Software without prior written authorization from 
> The Open Group.
>  extern void MoveOutline ( Window root, int x, int y, int width, int height,
>   int bw, int th );
>  extern void Zoom ( Window wf, Window wt );
> -extern char * ExpandFilename ( char *name );
> +extern char * ExpandFilename ( const char *name );
>  extern void GetUnknownIcon ( const char *name );
>  extern Pixmap FindBitmap ( const char *name, unsigned int *widthp,
>unsigned int *heightp );
> --
> 2.5.2
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH:twm] Add some const.

[Jasper St. Pierre]

I was imagining that it might be used like:

char *foo = ExpandFilename(name);
...
if (foo != name)
free(foo);

... which would still work, but the != is now dead code. If callers
were unconditionally freeing before, I heavily suspect something more
serious here.

On Wed, Sep 23, 2015 at 9:30 AM, Thomas Klausner <w...@netbsd.org> wrote:
> Well, yes, but for context, here is the full function after the change:
>
> char *
> ExpandFilename(const char *name)
> {
> char *newname;
>
> if (name[0] != '~') return strdup(name);
>
> newname = malloc (HomeLen + strlen(name) + 2);
> if (!newname) {
> fprintf (stderr,
>  "%s:  unable to allocate %ld bytes to expand filename 
> %s/%s\n",
>  ProgramName, HomeLen + (unsigned long)strlen(name) + 2,
>  Home, [1]);
> } else {
> (void) sprintf (newname, "%s/%s", Home, [1]);
> }
>
> return newname;
> }
>
> So in other words, now the function is consistent in returning a
> malloc()ed string when it succeeds.
>  Thomas
>
> On Wed, Sep 23, 2015 at 08:59:22AM -0700, Jasper St. Pierre wrote:
>> Should also mention that it also adds a strdup -- I feel that the code
>> calling this might conditionally free. Would be nice to double-check
>> callers.
>>
>> On Wed, Sep 23, 2015 at 1:58 AM, Thomas Klausner <w...@netbsd.org> wrote:
>> > From: Christos Zoulas <chris...@netbsd.org>
>> >
>> > Signed-off-by: Thomas Klausner <w...@netbsd.org>
>> > ---
>> >  src/util.c | 4 ++--
>> >  src/util.h | 2 +-
>> >  2 files changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/src/util.c b/src/util.c
>> > index 4b94051..5e8f0db 100644
>> > --- a/src/util.c
>> > +++ b/src/util.c
>> > @@ -256,11 +256,11 @@ Zoom(Window wf, Window wt)
>> >   *  \param name  the filename to expand
>> >   */
>> >  char *
>> > -ExpandFilename(char *name)
>> > +ExpandFilename(const char *name)
>> >  {
>> >  char *newname;
>> >
>> > -if (name[0] != '~') return name;
>> > +if (name[0] != '~') return strdup(name);
>> >
>> >  newname = malloc (HomeLen + strlen(name) + 2);
>> >  if (!newname) {
>> > diff --git a/src/util.h b/src/util.h
>> > index 7f4527c..4b2d3a8 100644
>> > --- a/src/util.h
>> > +++ b/src/util.h
>> > @@ -64,7 +64,7 @@ in this Software without prior written authorization 
>> > from The Open Group.
>> >  extern void MoveOutline ( Window root, int x, int y, int width, int 
>> > height,
>> >   int bw, int th );
>> >  extern void Zoom ( Window wf, Window wt );
>> > -extern char * ExpandFilename ( char *name );
>> > +extern char * ExpandFilename ( const char *name );
>> >  extern void GetUnknownIcon ( const char *name );
>> >  extern Pixmap FindBitmap ( const char *name, unsigned int *widthp,
>> >unsigned int *heightp );
>> > --
>> > 2.5.2
>> >
>> > ___
>> > xorg-devel@lists.x.org: X.Org development
>> > Archives: http://lists.x.org/archives/xorg-devel
>> > Info: http://lists.x.org/mailman/listinfo/xorg-devel
>>
>>
>>
>> --
>>   Jasper
>>



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [Xcb] [PATCH Xlib 1/3] Hoist most of _XConnectXCB into XOpenDisplay, and simplify

[Jasper St. Pierre]

Why not use -displayfd to get the display number to connect to? This
patch is still a good idea, I think, but it's not required.

On Wed, Jun 17, 2015 at 12:28 PM, Mike Blumenkrantz zm...@samsung.com wrote:
 On Thu, 11 Jun 2015 16:54:36 -0400
 Mike Blumenkrantz zm...@samsung.com wrote:

 On Thu, 11 Jun 2015 12:37:10 -0700
 Alan Coopersmith alan.coopersm...@oracle.com wrote:

  On 06/11/15 11:24 AM, Mike Blumenkrantz wrote:
   Commit by Josh Triplett and Jamey Sharp.
 
  Why is this useful?  It would really help if the commit comment had
  explanation, as suggested in
  http://who-t.blogspot.com/2009/12/on-commit-messages.html -
  otherwise it's a hard to review code dump, which for X, probably
  means it goes nowhere, as we don't have enough reviewers to reverse
  engineer code changes.
 

 This is a prep commit for the function added later in the series. It
 refactors the code to reduce duplication later on when there are two
 functions which will be using the same code paths.

 To elaborate further, this patch series will be useful for anyone
 wishing to implement XWayland functionality using Xlib. The
 X11 connection must be opened from a file descriptor using XCB, and so
 some method of opening a Display object from that XCB connection is
 necessary. These patches add that method while reducing code
 duplication to a minimum and, hopefully, still allowing multithreaded
 Xlib connections to function as expected.
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Nested procedures into X12

[Jasper St. Pierre]

One lets us submit all the requests in one go and get notified if an
error happens. The other requires us to synchronously ping-pong
to/from the server.

On Wed, Jun 17, 2015 at 5:06 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
 On Wed, Jun 17, 2015 at 02:05:59PM -0700, Jasper St. Pierre wrote:
 For context, when we receive a MapNotify from the server, we have a
 number of round-trips with the server.

 First, there's the XGetWindowAttributes. It would be convenient to
 have that along with the MapNotify, but not really a big deal.

 We implement our own XCB-style async XGetWindowProperty (which we
 should probably replace with actual xcb these days), so that's one
 round-trip.

 There's also the round-trips with setting up decorated windows
 (InternAtom and other things that happen on the first window).

 ... but this is dwarfed by XIGrabKeycode, which makes a total of 92
 round-trips for one window, to set up window keybindings. This is
 because the developers of XInput decided that they would helpfully
 return which masks failed to grab, instead of returning an error.

 and how is this different? what do you when one of the 92 single requests
 fails? either you ignore the error or you unroll and ungrab all previously
 requested ones, right?

 How is this different to doing the same when you have a mask that failed to
 grab?

 Cheers,
Peter


 And yet it's still fast enough. Eliminating roundtrips would be nice,
 but we should make sure we're eliminating the roundtrips that matter.

 On Wed, Jun 17, 2015 at 12:44 PM, Adam Jackson a...@nwnk.net wrote:
  On Wed, 2015-06-17 at 10:50 -0700, Keith Packard wrote:
 
  I thought we'd seen a proposal to add a new Fixes request that
  selected
  for specific property events; that would certainly be easy to add.
 
  From me, even:
 
  http://patchwork.freedesktop.org/patch/8050/
 
  I hadn't thought to also make it emit a generic event and include the
  property value in that proposal.  Would be nice for pagers and window
  managers though, since you end up needing a ton of _NET_WM_FOO on every
  window.  (Admittedly metacity and descendents roll their own async
  GetWindowProperty so it's only _one_ round trip, but.)
 
  Using an enormous API like OpenGL in every application isn't an
  obvious
  win though; the cost of setting up and maintaining all of that state
  is
  still non-trivial, especially for text rendering.
 
  I mean, sure, GL's not ideal, that's why they keep chopping stuff off
  it, core contexts and GLES and soon vulkan.  But I'm pretty sure we
  put all this rendering stuff in the server because we didn't have
  shared libraries is a story I've heard from you.
 
  Should there be some common rendering API?  Yeah probably.  Should it
  live in the presentation server?  Probably not, but the SI isn't built
  like that.
 
  The only non-trivial operations in X are ridiculous rendering
  requests;
  so we need to execute those asynchronously with respect to other X
  requests. Doing rendering entirely within the client is one solution,
  one wonders if there might not be others?
 
  I'm not really interested in trying to split ridiculous rendering to a
  server thread, if that's what we're talking about.  X's atomicity
  requirements make that pretty gross.
 
  - ajax
  ___
  xorg-devel@lists.x.org: X.Org development
  Archives: http://lists.x.org/archives/xorg-devel
  Info: http://lists.x.org/mailman/listinfo/xorg-devel



 --
   Jasper
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Nested procedures into X12

[Jasper St. Pierre]

For context, when we receive a MapNotify from the server, we have a
number of round-trips with the server.

First, there's the XGetWindowAttributes. It would be convenient to
have that along with the MapNotify, but not really a big deal.

We implement our own XCB-style async XGetWindowProperty (which we
should probably replace with actual xcb these days), so that's one
round-trip.

There's also the round-trips with setting up decorated windows
(InternAtom and other things that happen on the first window).

... but this is dwarfed by XIGrabKeycode, which makes a total of 92
round-trips for one window, to set up window keybindings. This is
because the developers of XInput decided that they would helpfully
return which masks failed to grab, instead of returning an error.

And yet it's still fast enough. Eliminating roundtrips would be nice,
but we should make sure we're eliminating the roundtrips that matter.

On Wed, Jun 17, 2015 at 12:44 PM, Adam Jackson a...@nwnk.net wrote:
 On Wed, 2015-06-17 at 10:50 -0700, Keith Packard wrote:

 I thought we'd seen a proposal to add a new Fixes request that
 selected
 for specific property events; that would certainly be easy to add.

 From me, even:

 http://patchwork.freedesktop.org/patch/8050/

 I hadn't thought to also make it emit a generic event and include the
 property value in that proposal.  Would be nice for pagers and window
 managers though, since you end up needing a ton of _NET_WM_FOO on every
 window.  (Admittedly metacity and descendents roll their own async
 GetWindowProperty so it's only _one_ round trip, but.)

 Using an enormous API like OpenGL in every application isn't an
 obvious
 win though; the cost of setting up and maintaining all of that state
 is
 still non-trivial, especially for text rendering.

 I mean, sure, GL's not ideal, that's why they keep chopping stuff off
 it, core contexts and GLES and soon vulkan.  But I'm pretty sure we
 put all this rendering stuff in the server because we didn't have
 shared libraries is a story I've heard from you.

 Should there be some common rendering API?  Yeah probably.  Should it
 live in the presentation server?  Probably not, but the SI isn't built
 like that.

 The only non-trivial operations in X are ridiculous rendering
 requests;
 so we need to execute those asynchronously with respect to other X
 requests. Doing rendering entirely within the client is one solution,
 one wonders if there might not be others?

 I'm not really interested in trying to split ridiculous rendering to a
 server thread, if that's what we're talking about.  X's atomicity
 requirements make that pretty gross.

 - ajax
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] glamor: don't do render ops with matching source/dest

[Jasper St. Pierre]

I wonder if we should tell the Qt people about this so they can get
back on the fast path?

In any case, makes sense.

Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net

On Wed, May 27, 2015 at 10:31 PM, Dave Airlie airl...@gmail.com wrote:
 From: Dave Airlie airl...@redhat.com

 XRender defines this, GL really doesn't like it.

 kwin 4.x and qt 4.x seem to make this happen for the
 gradient in the titlebar, and on radeonsi/r600 hw
 this draws all kinds of wrong.

 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
  glamor/glamor_render.c | 8 
  1 file changed, 8 insertions(+)

 diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
 index efca367..b3046b4 100644
 --- a/glamor/glamor_render.c
 +++ b/glamor/glamor_render.c
 @@ -1149,6 +1149,14 @@ glamor_composite_with_shader(CARD8 op,
  glamor_composite_shader *shader = NULL, *shader_ca = NULL;
  struct blendinfo op_info, op_info_ca;

 +if (source_pixmap == dest_pixmap) {
 +glamor_fallback(source and dest pixmaps are the same\n);
 +return ret;
 +}
 +if (mask_pixmap == dest_pixmap) {
 +glamor_fallback(mask and dest pixmaps are the same\n);
 +return ret;
 +}
  if (!glamor_composite_choose_shader(op, source, mask, dest,
  source_pixmap, mask_pixmap, 
 dest_pixmap,
  source_pixmap_priv, mask_pixmap_priv,
 --
 1.8.3.1

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xwayland 4/4] xwayland: Make the XYToWindowProc implementation aware of touchpoints

[Jasper St. Pierre]

I'm planning on removing this hook and just make compositors deal with
the fallout. Unfortunately, it hasn't been merged yet.

http://patchwork.freedesktop.org/patch/43021/

On Wed, May 27, 2015 at 9:42 AM, Carlos Garnacho carl...@gnome.org wrote:
 For these, we must first lookup the DIX sequence from the Sprite, we can
 then lookup the DDX ID/xwl_touch from xwayland's touch device.

 Signed-off-by: Carlos Garnacho carl...@gnome.org
 ---
  hw/xwayland/xwayland-input.c | 68 
 +++-
  1 file changed, 55 insertions(+), 13 deletions(-)

 diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
 index 3229c54..9d554a8 100644
 --- a/hw/xwayland/xwayland-input.c
 +++ b/hw/xwayland/xwayland-input.c
 @@ -818,29 +818,71 @@ DDXRingBell(int volume, int pitch, int duration)
  {
  }

 -static WindowPtr
 -xwl_xy_to_window(ScreenPtr screen, SpritePtr sprite, int x, int y)
 +static int32_t
 +lookup_sprite_touch_client_id (SpritePtr sprite)
  {
 -struct xwl_seat *xwl_seat = NULL;
  DeviceIntPtr device;
 +int i;

  for (device = inputInfo.devices; device; device = device-next) {
 -if (device-deviceProc == xwl_pointer_proc 
 -device-spriteInfo-sprite == sprite) {
 -xwl_seat = device-public.devicePrivate;
 -break;
 +if (!device-touch)
 +continue;
 +
 +for (i = 0; i  device-touch-num_touches; i++) {
 +TouchPointInfoPtr ti = device-touch-touches + i;
 +
 +if (sprite == ti-sprite)
 +return ti-client_id;
  }
  }

 -if (xwl_seat == NULL) {
 -/* XTEST device */
 -sprite-spriteTraceGood = 1;
 -return sprite-spriteTrace[0];
 +return 0;
 +}
 +
 +static struct xwl_touch *
 +xwl_touch_lookup_from_client_id (struct xwl_seat *xwl_seat, int32_t 
 client_id)
 +{
 +DeviceIntPtr touch = xwl_seat-touch;
 +int i;
 +
 +for (i = 0; i  touch-last.num_touches; i++) {
 +DDXTouchPointInfoPtr ddx_ti = touch-last.touches + i;
 +
 +if (ddx_ti-client_id == client_id)
 +return xwl_seat_lookup_touch(xwl_seat, ddx_ti-ddx_id);
 +}
 +
 +return NULL;
 +}
 +
 +static WindowPtr
 +xwl_xy_to_window(ScreenPtr screen, SpritePtr sprite, int x, int y)
 +{
 +struct xwl_screen *xwl_screen;
 +struct xwl_seat *xwl_seat = NULL;
 +struct xwl_window *xwl_window = NULL;
 +struct xwl_touch *xwl_touch;
 +int32_t client_id;
 +
 +xwl_screen = xwl_screen_get(screen);
 +
 +xorg_list_for_each_entry(xwl_seat, xwl_screen-seat_list, link) {
 +if (xwl_seat-pointer-spriteInfo-sprite == sprite) {
 +xwl_window = xwl_seat-focus_window;
 +} else if ((client_id = lookup_sprite_touch_client_id (sprite)) != 
 0) {
 +xwl_touch = xwl_touch_lookup_from_client_id (xwl_seat, 
 client_id);
 +
 +if (xwl_touch)
 +xwl_window = xwl_touch-window;
 +}
 +
 +if (xwl_window)
 +break;
  }

 -if (xwl_seat-focus_window) {
 +if (xwl_window) {
  sprite-spriteTraceGood = 2;
 -sprite-spriteTrace[1] = xwl_seat-focus_window-window;
 +sprite-spriteTrace[1] = xwl_window-window;
  return miSpriteTrace(sprite, x, y);
  }
  else {
 --
 2.4.1

 ___
 wayland-devel mailing list
 wayland-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xwayland] xwayland: Throttle our cursor surface updates with a frame callback

[Jasper St. Pierre]

This makes sense to me.

Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net

On Mon, May 25, 2015 at 12:15 PM, Rui Matos tiagoma...@gmail.com wrote:
 In some extreme cases with animated cursors at a high frame rate we
 could end up filling the wl_display outgoing buffer and end up with
 wl_display_flush() failing.

 In any case, using the frame callback to throttle ourselves is the
 right thing to do.

 Signed-off-by: Rui Matos tiagoma...@gmail.com
 ---
  hw/xwayland/xwayland-cursor.c | 20 
  hw/xwayland/xwayland-input.c  |  2 ++
  hw/xwayland/xwayland.h|  1 +
  3 files changed, 23 insertions(+)

 diff --git a/hw/xwayland/xwayland-cursor.c b/hw/xwayland/xwayland-cursor.c
 index 5a9d1fe..3ba5ad6 100644
 --- a/hw/xwayland/xwayland-cursor.c
 +++ b/hw/xwayland/xwayland-cursor.c
 @@ -82,6 +82,19 @@ xwl_unrealize_cursor(DeviceIntPtr device, ScreenPtr 
 screen, CursorPtr cursor)
  return xwl_shm_destroy_pixmap(pixmap);
  }

 +static void
 +frame_callback(void *data,
 +   struct wl_callback *callback,
 +   uint32_t time)
 +{
 +struct xwl_seat *xwl_seat = data;
 +xwl_seat-cursor_frame_cb = NULL;
 +}
 +
 +static const struct wl_callback_listener frame_listener = {
 +frame_callback
 +};
 +
  void
  xwl_seat_set_cursor(struct xwl_seat *xwl_seat)
  {
 @@ -98,6 +111,9 @@ xwl_seat_set_cursor(struct xwl_seat *xwl_seat)
  return;
  }

 +if (xwl_seat-cursor_frame_cb)
 +return;
 +
  cursor = xwl_seat-x_cursor;
  pixmap = dixGetPrivate(cursor-devPrivates, xwl_cursor_private_key);
  stride = cursor-bits-width * 4;
 @@ -117,6 +133,10 @@ xwl_seat_set_cursor(struct xwl_seat *xwl_seat)
  wl_surface_damage(xwl_seat-cursor, 0, 0,
xwl_seat-x_cursor-bits-width,
xwl_seat-x_cursor-bits-height);
 +
 +xwl_seat-cursor_frame_cb = wl_surface_frame(xwl_seat-cursor);
 +wl_callback_add_listener(xwl_seat-cursor_frame_cb, frame_listener, 
 xwl_seat);
 +
  wl_surface_commit(xwl_seat-cursor);
  }

 diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
 index 5230d8c..a3142f4 100644
 --- a/hw/xwayland/xwayland-input.c
 +++ b/hw/xwayland/xwayland-input.c
 @@ -586,6 +586,8 @@ xwl_seat_destroy(struct xwl_seat *xwl_seat)
  RemoveDevice(xwl_seat-keyboard, FALSE);
  wl_seat_destroy(xwl_seat-seat);
  wl_surface_destroy(xwl_seat-cursor);
 +if (xwl_seat-cursor_frame_cb)
 +wl_callback_destroy(xwl_seat-cursor_frame_cb);
  wl_array_release(xwl_seat-keys);
  free(xwl_seat);
  }
 diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
 index bfffa71..92d6d6e 100644
 --- a/hw/xwayland/xwayland.h
 +++ b/hw/xwayland/xwayland.h
 @@ -116,6 +116,7 @@ struct xwl_seat {
  struct wl_keyboard *wl_keyboard;
  struct wl_array keys;
  struct wl_surface *cursor;
 +struct wl_callback *cursor_frame_cb;
  struct xwl_window *focus_window;
  uint32_t id;
  uint32_t pointer_enter_serial;
 --
 2.4.0

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH v2 2/4] Free the data returned by XGetWindowProperty()

[Jasper St. Pierre]

XFree crashes when passed NULL.

On Thu, May 21, 2015 at 6:11 AM, walter harms wha...@bfs.de wrote:


 Am 21.05.2015 14:55, schrieb Eirik Byrkjeflot Anonsen:
 Signed-off-by: Eirik Byrkjeflot Anonsen ei...@eirikba.org
 ---
  xprop.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

 diff --git a/xprop.c b/xprop.c
 index ba23b87..4576db6 100644
 --- a/xprop.c
 +++ b/xprop.c
 @@ -1442,9 +1442,15 @@ Get_Window_Property_Data_And_Type (Atom atom,
  unsigned long nitems;
  unsigned long nbytes;
  unsigned long bytes_after;
 -unsigned char *prop;
 +static unsigned char *prop = NULL;
  int status;
 -
 +
 +if (prop)
 +{
 + XFree(prop);
 + prop = NULL;
 +}
 +


 let free() handle prop==NULL

 but in general the caller is responsible to free the memory

 re,
  wh

  status = XGetWindowProperty(dpy, target_win, atom, 0, (max_len+3)/4,
   False, AnyPropertyType, actual_type,
   actual_format, nitems, bytes_after,
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH v2 1/3] xwayland: Fix the addition and removal of outputs

[Jasper St. Pierre]

Expecting anything atomic from X11 in the first place is a wrong assumption.

On Thu, May 21, 2015 at 6:18 AM, Marek Chalupa mchqwe...@gmail.com wrote:
 Hi,

 On Sat, May 16, 2015 at 7:38 AM, Dima Ryazanov d...@gmail.com wrote:

 Add the output to the list when it's created rather than when its
 properties
 change (as pointed out by Marek Chalupa).
 Remove the output from the list when it's destroyed.

 Signed-off-by: Dima Ryazanov d...@gmail.com
 ---
  hw/xwayland/xwayland-output.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

 diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
 index 155cbc1..9baf4eb 100644
 --- a/hw/xwayland/xwayland-output.c
 +++ b/hw/xwayland/xwayland-output.c
 @@ -120,8 +120,6 @@ output_handle_done(void *data, struct wl_output
 *wl_output)
  struct xwl_screen *xwl_screen = xwl_output-xwl_screen;
  int width, height;

 -xorg_list_append(xwl_output-link, xwl_screen-output_list);
 -


 As I pointed out in the other e-mail: I don't think this is right. The
 append is here on purpose to make the output update atomic.
 But maybe somebody more erudated should review it :)


  width = 0;
  height = 0;
  xorg_list_for_each_entry(xwl_output, xwl_screen-output_list, link)
 {
 @@ -177,6 +175,8 @@ xwl_output_create(struct xwl_screen *xwl_screen,
 uint32_t id)
  xwl_output-randr_crtc = RRCrtcCreate(xwl_screen-screen,
 xwl_output);
  xwl_output-randr_output = RROutputCreate(xwl_screen-screen, name,
strlen(name), xwl_output);
 +xorg_list_append(xwl_output-link, xwl_screen-output_list);
 +
  RRCrtcGammaSetSize(xwl_output-randr_crtc, 256);
  RROutputSetCrtcs(xwl_output-randr_output, xwl_output-randr_crtc,
 1);
  RROutputSetConnection(xwl_output-randr_output, RR_Connected);
 @@ -190,6 +190,7 @@ xwl_output_destroy(struct xwl_output *xwl_output)
  wl_output_destroy(xwl_output-output);
  RRCrtcDestroy(xwl_output-randr_crtc);
  RROutputDestroy(xwl_output-randr_output);
 +xorg_list_del(xwl_output-link);
  free(xwl_output);
  }

 --
 2.4.0



 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] Allow system call restarts upon signal interruption

[Jasper St. Pierre]

(Resending from the email address I'm subscribed to, sorry for the noise)

I don't see how that's the case. The select() call should never block, see:

http://cgit.freedesktop.org/xorg/xserver/tree/os/connection.c#n1000

From select(2):

If both fields of the timeval structure are zero, then select()
returns immediately.

On Tue, May 12, 2015 at 7:18 PM, Michel Dänzer mic...@daenzer.net wrote:
 On 13.05.2015 07:39, Daniel Drake wrote:
 The X server frequently deals with SIGIO and SIGALRM interruptions.
 If process execution is inside certain blocking system calls
 when these signals arrive, e.g. with the kernel blocked on
 a contended semaphore, the system calls will be interrupted.

 Some system calls are automatically restartable (the kernel re-executes
 them with the same parameters once the signal handler returns) but
 only if the signal handler allows it.

 Set SA_RESTART on the signal handlers to enable this convenient
 behaviour.

 The discussion about this on IRC sounded to me like we don't want to do
 this for both signals, because at least one of them should interrupt
 select(). My guess would be that SIGIO should interrupt select() and
 thus shouldn't use SA_RESTART.


 --
 Earthling Michel Dänzer   |   http://www.amd.com
 Libre software enthusiast | Mesa and X developer
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] Allow system call restarts upon signal interruption

[Jasper St. Pierre]

I don't see how that's the case. The select() call should never block, see:

http://cgit.freedesktop.org/xorg/xserver/tree/os/connection.c#n1000

From select(2):

If both fields of the timeval structure are zero, then select() returns
immediately.

On Tue, May 12, 2015 at 7:18 PM, Michel Dänzer mic...@daenzer.net wrote:

 On 13.05.2015 07:39, Daniel Drake wrote:
  The X server frequently deals with SIGIO and SIGALRM interruptions.
  If process execution is inside certain blocking system calls
  when these signals arrive, e.g. with the kernel blocked on
  a contended semaphore, the system calls will be interrupted.
 
  Some system calls are automatically restartable (the kernel re-executes
  them with the same parameters once the signal handler returns) but
  only if the signal handler allows it.
 
  Set SA_RESTART on the signal handlers to enable this convenient
  behaviour.

 The discussion about this on IRC sounded to me like we don't want to do
 this for both signals, because at least one of them should interrupt
 select(). My guess would be that SIGIO should interrupt select() and
 thus shouldn't use SA_RESTART.


 --
 Earthling Michel Dänzer   |   http://www.amd.com
 Libre software enthusiast | Mesa and X developer




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xf86-input-libinput 4/4] Add option ButtonMapping (#9206)

[Jasper St. Pierre]

Are you sure that's the correct Xorg bug? Goes to something related to
x86emu for me.

On Tue, Apr 28, 2015 at 4:51 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
 With a long entry in the man page to detail what this option does.
 Specifically, it's the xorg.conf equivalent to XSetPointerMapping(3), it
 doesn't do any physical button remappings, merely the logical ones. If the
 physical button isn't mapped to the right logical button by default, that's
 either a libiput bug or an xkcd 1172 issue.

 X.Org Bug 9206 http://bugs.freedesktop.org/show_bug.cgi?id=9206

 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
 ---
  man/libinput.man | 38 +
  src/libinput.c   | 57 
 +---
  2 files changed, 88 insertions(+), 7 deletions(-)

 diff --git a/man/libinput.man b/man/libinput.man
 index c5eaea5..3b2697e 100644
 --- a/man/libinput.man
 +++ b/man/libinput.man
 @@ -50,6 +50,19 @@ The mapping from device node to hardware is 
 system-dependent. Property:
  .BI Option \*qAccelSpeed\*q \*q float \*q
  Sets the pointer acceleration speed within the range [-1, 1]
  .TP 7
 +.BI Option \*qButtonMapping\*q \*q string \*q
 +Sets the logical button mapping for this device, see
 +XSetPointerMapping(__libmansuffix__). The string must be a
 +space-separated list of button mappings in the order of the
 +logical buttons on the device, starting with button 1.
 +The default mapping is 1 2 3 ... 32. A mapping of 0
 +deactivates the button. Multiple buttons can have the same mapping.
 +Invalid mapping strings are discarded and the default mapping
 +is used for all buttons. Buttons not specified in the user's mapping use the
 +default mapping. See section
 +.B BUTTON MAPPING
 +for more details.
 +.TP 7
  .BI Option \*qCalibrationMatrix\*q \*q string \*q
  A string of 9 space-separated floating point numbers.
  Sets the calibration matrix to the 3x3 matrix where the first row is (abc),
 @@ -167,6 +180,31 @@ The above properties have a
  .BI libinput property name Default
  equivalent that indicates the default value for this setting on this device.

 +.SH BUTTON MAPPING
 +X clients receive events with logical button numbers, where 1, 2, 3
 +are usually interpreted as left, middle, right and logical buttons 4, 5, 6,
 +7 are usually interpreted as scroll up, down, left, right. The fourth and
 +fifth physical buttons on a device will thus send logical buttons 8 and 9.
 +The
 +.B ButtonMapping
 +option adjusts the logical button mapping, it does not affect how a physical
 +button is mapped to a logical button.
 +.PP
 +Traditionally, a device was set to left-handed button mode by applying a
 +button mapping of
 +.B \*q3 2 1 ...\*q
 +On systems using the
 +.B libinput
 +__xservername__ input driver it is recommended to use the
 +.B LeftHanded
 +option instead. Adjusting the
 +.PP
 +The
 +.B libinput
 +__xservername__ input driver does not use the button mapping after setup.
 +Use XSetPointerMapping(__libmansuffix__) to modify the button mapping at
 +runtime.
 +
  .SH AUTHORS
  Peter Hutterer
  .SH SEE ALSO
 diff --git a/src/libinput.c b/src/libinput.c
 index 2db62ba..c7ab18c 100644
 --- a/src/libinput.c
 +++ b/src/libinput.c
 @@ -96,6 +96,8 @@ struct xf86libinput {
 float matrix[9];
 enum libinput_config_scroll_method scroll_method;
 enum libinput_config_click_method click_method;
 +
 +   unsigned char btnmap[MAX_BUTTONS + 1];
 } options;
  };

 @@ -440,7 +442,6 @@ xf86libinput_init_pointer(InputInfoPtr pInfo)
 int nbuttons = 7;
 int i;

 -   unsigned char btnmap[MAX_BUTTONS + 1];
 Atom btnlabels[MAX_BUTTONS];
 Atom axislabels[TOUCHPAD_NUM_AXES];

 @@ -451,11 +452,11 @@ xf86libinput_init_pointer(InputInfoPtr pInfo)
 }
 }

 -   init_button_map(btnmap, ARRAY_SIZE(btnmap));
 init_button_labels(btnlabels, ARRAY_SIZE(btnlabels));
 init_axis_labels(axislabels, ARRAY_SIZE(axislabels));

 -   InitPointerDeviceStruct((DevicePtr)dev, btnmap,
 +   InitPointerDeviceStruct((DevicePtr)dev,
 +   driver_data-options.btnmap,
 nbuttons,
 btnlabels,
 xf86libinput_ptr_ctl,
 @@ -488,7 +489,6 @@ xf86libinput_init_pointer_absolute(InputInfoPtr pInfo)
 int nbuttons = 7;
 int i;

 -   unsigned char btnmap[MAX_BUTTONS + 1];
 Atom btnlabels[MAX_BUTTONS];
 Atom axislabels[TOUCHPAD_NUM_AXES];

 @@ -499,11 +499,11 @@ xf86libinput_init_pointer_absolute(InputInfoPtr pInfo)
 }
 }

 -   init_button_map(btnmap, ARRAY_SIZE(btnmap));
 init_button_labels(btnlabels, ARRAY_SIZE(btnlabels));
 init_axis_labels(axislabels, ARRAY_SIZE(axislabels));

 -   InitPointerDeviceStruct((DevicePtr)dev, btnmap,
 +   

[PATCH] composite: Don't bother copying the pixmap for ForgetGravity windows (v2)

[Jasper St. Pierre]

If a window has ForgetGravity in its bitGravity, that very likely
means it will repaint on the ConfigureNotify / Expose event, and thus
we don't have to copy the old pixmap into the new pixmap, we can simply
leave it blank.

Preventing this copy is super simple to do and a big win on small
devices where these blits can be expensive.

A better approach would be to actually obey BitGravity correctly rather
than assume NorthWestGravity always, but this is a big speedup for the
common case.

v2: Check all subwindows to make sure they are also ForgetGravity

Cc: Adam Jackson a...@redhat.com
Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net
---
 composite/compalloc.c | 109 +-
 1 file changed, 63 insertions(+), 46 deletions(-)

diff --git a/composite/compalloc.c b/composite/compalloc.c
index 8daded0..40bf873 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -526,6 +526,21 @@ compUnredirectOneSubwindow(WindowPtr pParent, WindowPtr 
pWin)
 return Success;
 }
 
+static Bool
+needsPixmapCopy(WindowPtr pWin)
+{
+WindowPtr pChild;
+
+if (pWin-bitGravity != ForgetGravity)
+return TRUE;
+
+for (pChild = pWin-firstChild; pChild; pChild = pChild-nextSib)
+if (needsPixmapCopy(pChild))
+return TRUE;
+
+return FALSE;
+}
+
 static PixmapPtr
 compNewPixmap(WindowPtr pWin, int x, int y, int w, int h)
 {
@@ -542,54 +557,56 @@ compNewPixmap(WindowPtr pWin, int x, int y, int w, int h)
 pPixmap-screen_x = x;
 pPixmap-screen_y = y;
 
-if (pParent-drawable.depth == pWin-drawable.depth) {
-GCPtr pGC = GetScratchGC(pWin-drawable.depth, pScreen);
-
-if (pGC) {
-ChangeGCVal val;
-
-val.val = IncludeInferiors;
-ChangeGC(NullClient, pGC, GCSubwindowMode, val);
-ValidateGC(pPixmap-drawable, pGC);
-(*pGC-ops-CopyArea) (pParent-drawable,
-   pPixmap-drawable,
-   pGC,
-   x - pParent-drawable.x,
-   y - pParent-drawable.y, w, h, 0, 0);
-FreeScratchGC(pGC);
+if (needsPixmapCopy(pWin)) {
+if (pParent-drawable.depth == pWin-drawable.depth) {
+GCPtr pGC = GetScratchGC(pWin-drawable.depth, pScreen);
+
+if (pGC) {
+ChangeGCVal val;
+
+val.val = IncludeInferiors;
+ChangeGC(NullClient, pGC, GCSubwindowMode, val);
+ValidateGC(pPixmap-drawable, pGC);
+(*pGC-ops-CopyArea) (pParent-drawable,
+   pPixmap-drawable,
+   pGC,
+   x - pParent-drawable.x,
+   y - pParent-drawable.y, w, h, 0, 0);
+FreeScratchGC(pGC);
+}
 }
-}
-else {
-PictFormatPtr pSrcFormat = PictureWindowFormat(pParent);
-PictFormatPtr pDstFormat = PictureWindowFormat(pWin);
-XID inferiors = IncludeInferiors;
-int error;
-
-PicturePtr pSrcPicture = CreatePicture(None,
-   pParent-drawable,
-   pSrcFormat,
-   CPSubwindowMode,
-   inferiors,
-   serverClient, error);
-
-PicturePtr pDstPicture = CreatePicture(None,
-   pPixmap-drawable,
-   pDstFormat,
-   0, 0,
-   serverClient, error);
-
-if (pSrcPicture  pDstPicture) {
-CompositePicture(PictOpSrc,
- pSrcPicture,
- NULL,
- pDstPicture,
- x - pParent-drawable.x,
- y - pParent-drawable.y, 0, 0, 0, 0, w, h);
+else {
+PictFormatPtr pSrcFormat = PictureWindowFormat(pParent);
+PictFormatPtr pDstFormat = PictureWindowFormat(pWin);
+XID inferiors = IncludeInferiors;
+int error;
+
+PicturePtr pSrcPicture = CreatePicture(None,
+   pParent-drawable,
+   pSrcFormat,
+   CPSubwindowMode,
+   inferiors,
+   serverClient, error);
+
+PicturePtr pDstPicture = CreatePicture(None,
+   pPixmap-drawable,
+   pDstFormat

[PATCH] xf86Mode: Don't make the mode name a const char *

[Jasper St. Pierre]

const implies that the pointer is in static memory, and could easily
make people not free it after calling xf86DuplicateMode out of
confusion. Change it back to a char *, and fix up callers to respect
that.
---
 hw/xfree86/common/xf86Mode.c|  2 +-
 hw/xfree86/common/xf86VidMode.c | 18 +-
 hw/xfree86/common/xf86str.h |  2 +-
 hw/xfree86/fbdevhw/fbdevhw.c|  2 +-
 hw/xfree86/modes/xf86Modes.c|  2 +-
 5 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/hw/xfree86/common/xf86Mode.c b/hw/xfree86/common/xf86Mode.c
index 9a5550f..495262e 100644
--- a/hw/xfree86/common/xf86Mode.c
+++ b/hw/xfree86/common/xf86Mode.c
@@ -1998,7 +1998,7 @@ xf86DeleteMode(DisplayModePtr * modeList, DisplayModePtr 
mode)
 mode-next-prev = mode-prev;
 }
 
-free((void *) mode-name);
+free(mode-name);
 free(mode);
 }
 
diff --git a/hw/xfree86/common/xf86VidMode.c b/hw/xfree86/common/xf86VidMode.c
index e708b27..efd4453 100644
--- a/hw/xfree86/common/xf86VidMode.c
+++ b/hw/xfree86/common/xf86VidMode.c
@@ -421,22 +421,22 @@ VidModeSetCrtcForMode(int scrnIndex, void *mode)
 }
 
 Bool
-VidModeAddModeline(int scrnIndex, void *mode)
+VidModeAddModeline(int scrnIndex, void *mode_)
 {
 ScrnInfoPtr pScrn;
+DisplayModePtr mode = mode_;
 
 if ((mode == NULL) || (!VidModeAvailable(scrnIndex)))
 return FALSE;
 
 pScrn = xf86Screens[scrnIndex];
 
-((DisplayModePtr) mode)-name = strdup(); /* freed by deletemode */
-((DisplayModePtr) mode)-status = MODE_OK;
-((DisplayModePtr) mode)-next = pScrn-modes-next;
-((DisplayModePtr) mode)-prev = pScrn-modes;
-pScrn-modes-next = (DisplayModePtr) mode;
-if (((DisplayModePtr) mode)-next != NULL)
-((DisplayModePtr) mode)-next-prev = (DisplayModePtr) mode;
+mode-status = MODE_OK;
+mode-next = pScrn-modes-next;
+mode-prev = pScrn-modes;
+pScrn-modes-next = mode;
+if (mode-next != NULL)
+mode-next-prev = mode;
 
 return TRUE;
 }
@@ -533,7 +533,7 @@ VidModeCreateMode(void)
 
 mode = malloc(sizeof(DisplayModeRec));
 if (mode != NULL) {
-mode-name = ;
+mode-name = strdup(); /* freed by deletemode */
 mode-VScan = 1;/* divides refresh rate. default = 1 */
 mode-Private = NULL;
 mode-next = mode;
diff --git a/hw/xfree86/common/xf86str.h b/hw/xfree86/common/xf86str.h
index 643a65d..1d1c54b 100644
--- a/hw/xfree86/common/xf86str.h
+++ b/hw/xfree86/common/xf86str.h
@@ -145,7 +145,7 @@ typedef enum {
 typedef struct _DisplayModeRec {
 struct _DisplayModeRec *prev;
 struct _DisplayModeRec *next;
-const char *name;   /* identifier for the mode */
+char *name; /* identifier for the mode */
 ModeStatus status;
 int type;
 
diff --git a/hw/xfree86/fbdevhw/fbdevhw.c b/hw/xfree86/fbdevhw/fbdevhw.c
index 8cd2079..25baf2b 100644
--- a/hw/xfree86/fbdevhw/fbdevhw.c
+++ b/hw/xfree86/fbdevhw/fbdevhw.c
@@ -392,7 +392,7 @@ fbdevHWInit(ScrnInfoPtr pScrn, struct pci_device *pPci, 
char *device)
 
 /* we can use the current settings as buildin mode */
 fbdev2xfree_timing(fPtr-var, fPtr-buildin);
-fPtr-buildin.name = current;
+fPtr-buildin.name = (char *) current;
 fPtr-buildin.next = fPtr-buildin;
 fPtr-buildin.prev = fPtr-buildin;
 fPtr-buildin.type |= M_T_BUILTIN;
diff --git a/hw/xfree86/modes/xf86Modes.c b/hw/xfree86/modes/xf86Modes.c
index 43b2233..d56abda 100644
--- a/hw/xfree86/modes/xf86Modes.c
+++ b/hw/xfree86/modes/xf86Modes.c
@@ -131,7 +131,7 @@ xf86SetModeDefaultName(DisplayModePtr mode)
 Bool interlaced = ! !(mode-Flags  V_INTERLACE);
 char *tmp;
 
-free((void *) mode-name);
+free(mode-name);
 
 XNFasprintf(tmp, %dx%d%s, mode-HDisplay, mode-VDisplay,
 interlaced ? i : );
-- 
2.1.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] composite: Don't bother copying the pixmap for ForgetGravity windows (v2)

[Jasper St. Pierre]

The compositor sync protocol helps that tremendously, where the client
actually tells the compositor when it can start to use the new pixmap.
I tested with xcompmgr and nautilus, and couldn't see any flickering,
which tells me that clients are actually plenty fast enough already.

But yeah, you might see flickering in a worst case scenario. I'd argue
that isn't much better than the current NorthWestGravity behavior
where we lop off the bottom/right edge of the window. There's no true
way to solve this properly besides a Wayland-approach where the client
just presents the compositor a correctly-sized, finished pixmap.

On Thu, Apr 23, 2015 at 2:13 PM, Aaron Plattner aplatt...@nvidia.com wrote:
 Does this cause flickering when resizing windows and the compositor reads
 the new window pixmap before the app has a chance to respond to the events?


 On 04/23/2015 01:24 PM, Jasper St. Pierre wrote:

 If a window has ForgetGravity in its bitGravity, that very likely
 means it will repaint on the ConfigureNotify / Expose event, and thus
 we don't have to copy the old pixmap into the new pixmap, we can simply
 leave it blank.

 Preventing this copy is super simple to do and a big win on small
 devices where these blits can be expensive.

 A better approach would be to actually obey BitGravity correctly rather
 than assume NorthWestGravity always, but this is a big speedup for the
 common case.

 v2: Check all subwindows to make sure they are also ForgetGravity

 Cc: Adam Jackson a...@redhat.com
 Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net
 ---
   composite/compalloc.c | 109
 +-
   1 file changed, 63 insertions(+), 46 deletions(-)

 diff --git a/composite/compalloc.c b/composite/compalloc.c
 index 8daded0..40bf873 100644
 --- a/composite/compalloc.c
 +++ b/composite/compalloc.c
 @@ -526,6 +526,21 @@ compUnredirectOneSubwindow(WindowPtr pParent,
 WindowPtr pWin)
   return Success;
   }

 +static Bool
 +needsPixmapCopy(WindowPtr pWin)
 +{
 +WindowPtr pChild;
 +
 +if (pWin-bitGravity != ForgetGravity)
 +return TRUE;
 +
 +for (pChild = pWin-firstChild; pChild; pChild = pChild-nextSib)
 +if (needsPixmapCopy(pChild))
 +return TRUE;
 +
 +return FALSE;
 +}
 +
   static PixmapPtr
   compNewPixmap(WindowPtr pWin, int x, int y, int w, int h)
   {
 @@ -542,54 +557,56 @@ compNewPixmap(WindowPtr pWin, int x, int y, int w,
 int h)
   pPixmap-screen_x = x;
   pPixmap-screen_y = y;

 -if (pParent-drawable.depth == pWin-drawable.depth) {
 -GCPtr pGC = GetScratchGC(pWin-drawable.depth, pScreen);
 -
 -if (pGC) {
 -ChangeGCVal val;
 -
 -val.val = IncludeInferiors;
 -ChangeGC(NullClient, pGC, GCSubwindowMode, val);
 -ValidateGC(pPixmap-drawable, pGC);
 -(*pGC-ops-CopyArea) (pParent-drawable,
 -   pPixmap-drawable,
 -   pGC,
 -   x - pParent-drawable.x,
 -   y - pParent-drawable.y, w, h, 0, 0);
 -FreeScratchGC(pGC);
 +if (needsPixmapCopy(pWin)) {
 +if (pParent-drawable.depth == pWin-drawable.depth) {
 +GCPtr pGC = GetScratchGC(pWin-drawable.depth, pScreen);
 +
 +if (pGC) {
 +ChangeGCVal val;
 +
 +val.val = IncludeInferiors;
 +ChangeGC(NullClient, pGC, GCSubwindowMode, val);
 +ValidateGC(pPixmap-drawable, pGC);
 +(*pGC-ops-CopyArea) (pParent-drawable,
 +   pPixmap-drawable,
 +   pGC,
 +   x - pParent-drawable.x,
 +   y - pParent-drawable.y, w, h, 0,
 0);
 +FreeScratchGC(pGC);
 +}
   }
 -}
 -else {
 -PictFormatPtr pSrcFormat = PictureWindowFormat(pParent);
 -PictFormatPtr pDstFormat = PictureWindowFormat(pWin);
 -XID inferiors = IncludeInferiors;
 -int error;
 -
 -PicturePtr pSrcPicture = CreatePicture(None,
 -   pParent-drawable,
 -   pSrcFormat,
 -   CPSubwindowMode,
 -   inferiors,
 -   serverClient, error);
 -
 -PicturePtr pDstPicture = CreatePicture(None,
 -   pPixmap-drawable,
 -   pDstFormat,
 -   0, 0,
 -   serverClient, error);
 -
 -if (pSrcPicture  pDstPicture) {
 -CompositePicture(PictOpSrc,
 - pSrcPicture

[PATCH] composite: Don't bother copying the pixmap for ForgetGravity windows

[Jasper St. Pierre]

If a window has ForgetGravity in its bitGravity, that very likely
means it will repaint on the ConfigureNotify / Expose event, and thus
we don't have to copy the old pixmap into the new pixmap, we can simply
leave it blank.

Preventing this copy is super simple to do and a big win on small
devices where these blits can be expensive.

A better approach would be to actually obey BitGravity correctly rather
than assume NorthWestGravity always, but this is a big speedup for the
common case.
---
 composite/compalloc.c | 94 ++-
 1 file changed, 48 insertions(+), 46 deletions(-)

diff --git a/composite/compalloc.c b/composite/compalloc.c
index 8daded0..70c83f0 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -542,54 +542,56 @@ compNewPixmap(WindowPtr pWin, int x, int y, int w, int h)
 pPixmap-screen_x = x;
 pPixmap-screen_y = y;
 
-if (pParent-drawable.depth == pWin-drawable.depth) {
-GCPtr pGC = GetScratchGC(pWin-drawable.depth, pScreen);
-
-if (pGC) {
-ChangeGCVal val;
-
-val.val = IncludeInferiors;
-ChangeGC(NullClient, pGC, GCSubwindowMode, val);
-ValidateGC(pPixmap-drawable, pGC);
-(*pGC-ops-CopyArea) (pParent-drawable,
-   pPixmap-drawable,
-   pGC,
-   x - pParent-drawable.x,
-   y - pParent-drawable.y, w, h, 0, 0);
-FreeScratchGC(pGC);
+if (pWin-bitGravity != ForgetGravity) {
+if (pParent-drawable.depth == pWin-drawable.depth) {
+GCPtr pGC = GetScratchGC(pWin-drawable.depth, pScreen);
+
+if (pGC) {
+ChangeGCVal val;
+
+val.val = IncludeInferiors;
+ChangeGC(NullClient, pGC, GCSubwindowMode, val);
+ValidateGC(pPixmap-drawable, pGC);
+(*pGC-ops-CopyArea) (pParent-drawable,
+   pPixmap-drawable,
+   pGC,
+   x - pParent-drawable.x,
+   y - pParent-drawable.y, w, h, 0, 0);
+FreeScratchGC(pGC);
+}
 }
-}
-else {
-PictFormatPtr pSrcFormat = PictureWindowFormat(pParent);
-PictFormatPtr pDstFormat = PictureWindowFormat(pWin);
-XID inferiors = IncludeInferiors;
-int error;
-
-PicturePtr pSrcPicture = CreatePicture(None,
-   pParent-drawable,
-   pSrcFormat,
-   CPSubwindowMode,
-   inferiors,
-   serverClient, error);
-
-PicturePtr pDstPicture = CreatePicture(None,
-   pPixmap-drawable,
-   pDstFormat,
-   0, 0,
-   serverClient, error);
-
-if (pSrcPicture  pDstPicture) {
-CompositePicture(PictOpSrc,
- pSrcPicture,
- NULL,
- pDstPicture,
- x - pParent-drawable.x,
- y - pParent-drawable.y, 0, 0, 0, 0, w, h);
+else {
+PictFormatPtr pSrcFormat = PictureWindowFormat(pParent);
+PictFormatPtr pDstFormat = PictureWindowFormat(pWin);
+XID inferiors = IncludeInferiors;
+int error;
+
+PicturePtr pSrcPicture = CreatePicture(None,
+   pParent-drawable,
+   pSrcFormat,
+   CPSubwindowMode,
+   inferiors,
+   serverClient, error);
+
+PicturePtr pDstPicture = CreatePicture(None,
+   pPixmap-drawable,
+   pDstFormat,
+   0, 0,
+   serverClient, error);
+
+if (pSrcPicture  pDstPicture) {
+CompositePicture(PictOpSrc,
+ pSrcPicture,
+ NULL,
+ pDstPicture,
+ x - pParent-drawable.x,
+ y - pParent-drawable.y, 0, 0, 0, 0, w, h);
+}
+if (pSrcPicture)
+FreePicture(pSrcPicture, 0);
+if (pDstPicture)
+

Re: [PATCH xinit 1/2] startx: Fix startx picking an already used display number when -nolock is used

[Jasper St. Pierre]

... Why does displayfd imply nolock? That seems strange to me. I consider
the .X0-lock files an API that we shouldn't break.

On Fri, Mar 20, 2015 at 7:02 AM, Hans de Goede hdego...@redhat.com wrote:

 Currently startx relies on /tmp/.X?-lock being present for automatically
 picking a free display number. This does not work if -nolock is used when
 starting the server, or if the server is started with -displayfd as
 -displayfd
 implies -nolock.

 This is becoming a problem now that -displayfd is getting used by
 display-managers (e.g. gdm), this fixes this by also checking for
 /tmp/.X11-unix/X?

 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
  startx.cpp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/startx.cpp b/startx.cpp
 index 8520399..fe49996 100644
 --- a/startx.cpp
 +++ b/startx.cpp
 @@ -120,7 +120,7 @@ enable_xauth=1
  XCOMM Automatically determine an unused $DISPLAY
  d=0
  while true ; do
 -[ -e /tmp/.X$d-lock ] || break
 +[ -e /tmp/.X$d-lock -o -S /tmp/.X11-unix/X$d ] || break
  d=$(($d + 1))
  done
  defaultdisplay=:$d
 --
 2.3.3

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH] xwayland-input: Remove our XYToWindow handler

[Jasper St. Pierre]

This was built as a hack for simple Wayland compositors like Weston
which were lazy and didn't want to configure windows server-side when
moved.

Since comboboxes and menus are separate toplevel O-R windows, this hack
breaks input as it needs to be traced normally, not simply sent to the
focused window.

X11 toolkits really do need their windows to be configured correctly
for their O-R windows comboboxes or menus other things, so let's fix
the lazy compositors and remove this.

I have tested this patch with both Weston and Mutter and neither of
them require any changes, and it fixes comboboxes and menus.

If somebody then wants to revert 73698d4, that's fine by me, so we
reduce the amount of API that DDXen have.

Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net
---
 hw/xwayland/xwayland-input.c | 34 --
 hw/xwayland/xwayland.h   |  1 -
 2 files changed, 35 deletions(-)

diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index 5e20418..c825ef4 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -633,37 +633,6 @@ DDXRingBell(int volume, int pitch, int duration)
 {
 }
 
-static WindowPtr
-xwl_xy_to_window(ScreenPtr screen, SpritePtr sprite, int x, int y)
-{
-struct xwl_seat *xwl_seat = NULL;
-DeviceIntPtr device;
-
-for (device = inputInfo.devices; device; device = device-next) {
-if (device-deviceProc == xwl_pointer_proc 
-device-spriteInfo-sprite == sprite) {
-xwl_seat = device-public.devicePrivate;
-break;
-}
-}
-
-if (xwl_seat == NULL) {
-/* XTEST device */
-sprite-spriteTraceGood = 1;
-return sprite-spriteTrace[0];
-}
-
-if (xwl_seat-focus_window) {
-sprite-spriteTraceGood = 2;
-sprite-spriteTrace[1] = xwl_seat-focus_window-window;
-return miSpriteTrace(sprite, x, y);
-}
-else {
-sprite-spriteTraceGood = 1;
-return sprite-spriteTrace[0];
-}
-}
-
 void
 InitInput(int argc, char *argv[])
 {
@@ -676,9 +645,6 @@ InitInput(int argc, char *argv[])
 wl_registry_add_listener(xwl_screen-input_registry, input_listener,
  xwl_screen);
 
-xwl_screen-XYToWindow = pScreen-XYToWindow;
-pScreen-XYToWindow = xwl_xy_to_window;
-
 xwl_screen-expecting_event = 0;
 wl_display_roundtrip(xwl_screen-display);
 while (xwl_screen-expecting_event)
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index bfffa71..ce359d6 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -62,7 +62,6 @@ struct xwl_screen {
 DestroyWindowProcPtr DestroyWindow;
 RealizeWindowProcPtr RealizeWindow;
 UnrealizeWindowProcPtr UnrealizeWindow;
-XYToWindowProcPtr XYToWindow;
 
 struct xorg_list output_list;
 struct xorg_list seat_list;
-- 
2.1.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] xwayland-input: Don't assume all input is children of the focused window

[Jasper St. Pierre]

The guard window is supposed to be capturing input. That's the whole point.

We stack windows below the guard window when minimizing them so that input
won't go to them, but we can still show live-previews for them in Alt-Tab.

On Fri, Feb 20, 2015 at 4:57 AM, Daniel Stone dan...@fooishbar.org wrote:

 Hi,

 On 20 February 2015 at 09:47, Olivier Fourdan ofour...@redhat.com wrote:
  It works, as long as the window is not moved, as soon as the toplevel
 window
  is moved, the translated coordinates seem correct but the window
 returned by
  miSpriteTrace() is not, e.g. I get the mutter guard window instead of
 the
  actual expected window.

 miSpriteTrace is only supposed to test the input shape, so in this
 case shouldn't the guard window not be capturing input?

 Cheers,
 Daniel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] xwayland-input: Don't assume all input is children of the focused window

[Jasper St. Pierre]

On Fri, Feb 20, 2015 at 1:47 AM, Olivier Fourdan ofour...@redhat.com
wrote:

 Hi Jasper,

 I was working on the same issue (https://bugzilla.redhat.com/
 show_bug.cgi?id=1188289) but did not think about translating the
 coordinates!

 I applied your patch along with the patch for mutter (on mutter 3.14.3 as
 found in F21) not to map the cow but that does not work very well.

 It works, as long as the window is not moved, as soon as the toplevel
 window is moved, the translated coordinates seem correct but the window
 returned by miSpriteTrace() is not, e.g. I get the mutter guard window
 instead of the actual expected window.

 Oddly enough the coordinates of the toplevel xwindow (as seen with xprop)
 are not updated after the move, so that miSpriteTrace() picks the wrong
 window - Maybe I am missing some other patch in mutter, I'll check that.


Hm, that's strange. We should be configuring the toplevel window on every
move -- mutter still is an X11 WM. In fact, for the client to map the
combobox in the right place, the toplevel coordinates have to be correct.


 That being said, I don't think it's a good idea to make a disruptive
 change in Xwayland that requires code change in the Wayland compositors,
 what about Weston or the other Wayland compositors out there, we can't
 really expect all of them to change their code in a synchronously with
 Xwayland.


We don't require any changes in Weston, from what I can tell. The window
still has to be configured in the correct place for the O-R window to be
put in that location. If Weston doesn't configure the window, behavior will
be incorrect.


 We discussed that with ajax and halfline and the the idea would be rather
 to check if the cow exists and is mapped (e.g. as in mutter before your
 patch) then use the current code, otherwise, translate the coordinates as
 you did.


That doesn't make much sense to me. The issue we have is that the combobox
window isn't ever a child of the focused window, it's a separate O-R child
of the root. As such, we can't *ever* trace down from the focused window.


 i.e. something like that:

 --- a/hw/xwayland/xwayland-input.c
 +++ b/hw/xwayland/xwayland-input.c
 @@ -32,6 +32,9 @@
  #include xkbsrv.h
  #include xserver-properties.h
  #include inpututils.h
 +#ifdef COMPOSITE
 +#include compint.h
 +#endif

  static void
  xwl_pointer_control(DeviceIntPtr device, PtrCtrl *ctrl)
 @@ -628,8 +631,25 @@ xwl_xy_to_window(ScreenPtr screen, SpritePtr sprite,
 int x, int y)
  }

  if (xwl_seat-focus_window) {
 -sprite-spriteTraceGood = 2;
 -sprite-spriteTrace[1] = xwl_seat-focus_window-window;
 +#ifdef COMPOSITE
 +CompScreenPtr cs;
 +
 +/* The compositor may have mapped the COW.
 + * If this is the case, translating to the root coordinates to
 search
 + * for the window will give us the COW which we don't want, so
 use the
 + * seat's focused window with relative coordinates instead.
 + */
 +cs = GetCompScreen(screen);
 +if (cs-pOverlayWin  cs-pOverlayWin-mapped) {
 +   sprite-spriteTraceGood = 2;
 +   sprite-spriteTrace[1] = xwl_seat-focus_window-window;
 +   return miSpriteTrace(sprite, x, y);
 +}
 +#endif
 +/* convert to root coordinates */
 +x += xwl_seat-focus_window-window-drawable.x;
 +y += xwl_seat-focus_window-window-drawable.y;
 +sprite-spriteTraceGood = 1;
  return miSpriteTrace(sprite, x, y);
  }
  else {


 But we still need to make sure it works reliably with translated
 coordinates.

 Cheers,
 Olivier


 On 18/02/15 21:41, Jasper St. Pierre wrote:

 Some toolkits implement comboboxes or menus or other things through
 O-R windows, which aren't children of the focused window. In order to
 properly get input on them during grab conditions, we need to trace the
 whole input tree, not just the focused window down.

 Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net
 ---
   hw/xwayland/xwayland-input.c | 6 --
   1 file changed, 4 insertions(+), 2 deletions(-)

 diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
 index 5e20418..8b96bd2 100644
 --- a/hw/xwayland/xwayland-input.c
 +++ b/hw/xwayland/xwayland-input.c
 @@ -654,8 +654,10 @@ xwl_xy_to_window(ScreenPtr screen, SpritePtr sprite,
 int x, int y)
   }

   if (xwl_seat-focus_window) {
 -sprite-spriteTraceGood = 2;
 -sprite-spriteTrace[1] = xwl_seat-focus_window-window;
 +/* convert to root coordinates */
 +x += xwl_seat-focus_window-window-drawable.x;
 +y += xwl_seat-focus_window-window-drawable.y;
 +sprite-spriteTraceGood = 1;
   return miSpriteTrace(sprite, x, y);
   }
   else {





-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH] xwayland-input: Don't assume all input is children of the focused window

[Jasper St. Pierre]

Some toolkits implement comboboxes or menus or other things through
O-R windows, which aren't children of the focused window. In order to
properly get input on them during grab conditions, we need to trace the
whole input tree, not just the focused window down.

Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net
---
 hw/xwayland/xwayland-input.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index 5e20418..8b96bd2 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -654,8 +654,10 @@ xwl_xy_to_window(ScreenPtr screen, SpritePtr sprite, int 
x, int y)
 }
 
 if (xwl_seat-focus_window) {
-sprite-spriteTraceGood = 2;
-sprite-spriteTrace[1] = xwl_seat-focus_window-window;
+/* convert to root coordinates */
+x += xwl_seat-focus_window-window-drawable.x;
+y += xwl_seat-focus_window-window-drawable.y;
+sprite-spriteTraceGood = 1;
 return miSpriteTrace(sprite, x, y);
 }
 else {
-- 
2.1.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH] test/xi1: Update .gitignore

[Jasper St. Pierre]

---
 test/xi1/.gitignore | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 test/xi1/.gitignore

diff --git a/test/xi1/.gitignore b/test/xi1/.gitignore
new file mode 100644
index 000..c1b9024
--- /dev/null
+++ b/test/xi1/.gitignore
@@ -0,0 +1 @@
+protocol-xchangedevicecontrol
-- 
2.1.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 4/4] Check for __linux__ instead of linux during compilation

[Jasper St. Pierre]

This makes sense.

Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net

On Mon, Feb 9, 2015 at 1:56 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:

 Would anyone have some input - apart from the missing libpciaccess
 prefix of course ?
 Fwiw src/common_interface.c already checks for __linux__, so this
 patch makes things more consistent as an added bonus :-P

 Cheers,
 Emil

 On 6 February 2015 at 17:29, Emil Velikov emil.l.veli...@gmail.com
 wrote:
  From: Eero Tamminen eero.t.tammi...@intel.com
 
  __linux__ is the POSIX define for checking for Linux OS, linux is
  deprecated and apparently not supported by Android.
 
  Besides correcting the define, patch adds error for the case OS isn't
  unrecognized.
 
  Signed-off-by: Eero Tamminen eero.t.tammi...@intel.com
  [Emil Velikov: Remove irrelevant Android details from commit msg.]
  Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
  ---
   src/common_init.c | 4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)
 
  diff --git a/src/common_init.c b/src/common_init.c
  index a127a8b..b1c0c3e 100644
  --- a/src/common_init.c
  +++ b/src/common_init.c
  @@ -52,7 +52,7 @@ pci_system_init( void )
   {
   int err = ENOSYS;
 
  -#ifdef linux
  +#ifdef __linux__
   err = pci_system_linux_sysfs_create();
   #elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ||
 defined(__DragonFly__)
   err = pci_system_freebsd_create();
  @@ -64,6 +64,8 @@ pci_system_init( void )
   err = pci_system_solx_devfs_create();
   #elif defined(__GNU__) || defined(__CYGWIN__)
   err = pci_system_x86_create();
  +#else
  +# error Unsupported OS
   #endif
 
   return err;
  --
  2.2.2
 
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Start Xorg with background image

[Jasper St. Pierre]

-background none needs to be supported by the DDX to copy existing
framebuffer contents into the root window. What DDX are you using?

On Sun, Feb 8, 2015 at 10:37 PM, kirthika varadarajan 
kirthikai...@gmail.com wrote:

 Hi All,
  From linux driver I am writing an image to video buffer.

  When Xorg starts its clearing the video buffer and black screen is shown.
  Is there any way to retain the image in framebuffer which is written by
 driver when
  xorg starts.

 Any one have tried showing background image when Xorg starts or is there
 any way to modify Xorg library to retain the frame buffer contents.

  Also I tried xorg with option -background none but still its clearing the
 window.


  Suggest me the ways to retain the image.

 Thanks and Regards,
 Kiruthika

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 4/4] Check for __linux__ instead of linux during compilation

[Jasper St. Pierre]

What project is this for? There's no src/common_init.c in Xorg, of course.

On Fri, Feb 6, 2015 at 9:29 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:

 From: Eero Tamminen eero.t.tammi...@intel.com

 __linux__ is the POSIX define for checking for Linux OS, linux is
 deprecated and apparently not supported by Android.

 Besides correcting the define, patch adds error for the case OS isn't
 unrecognized.

 Signed-off-by: Eero Tamminen eero.t.tammi...@intel.com
 [Emil Velikov: Remove irrelevant Android details from commit msg.]
 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
 ---
  src/common_init.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/src/common_init.c b/src/common_init.c
 index a127a8b..b1c0c3e 100644
 --- a/src/common_init.c
 +++ b/src/common_init.c
 @@ -52,7 +52,7 @@ pci_system_init( void )
  {
  int err = ENOSYS;

 -#ifdef linux
 +#ifdef __linux__
  err = pci_system_linux_sysfs_create();
  #elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ||
 defined(__DragonFly__)
  err = pci_system_freebsd_create();
 @@ -64,6 +64,8 @@ pci_system_init( void )
  err = pci_system_solx_devfs_create();
  #elif defined(__GNU__) || defined(__CYGWIN__)
  err = pci_system_x86_create();
 +#else
 +# error Unsupported OS
  #endif

  return err;
 --
 2.2.2

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: 1.17 status and schedule

[Jasper St. Pierre]

I guess I should follow up with that I don't really care how the patch ends
up or which six colors of the bikeshed we end up choosing. I just want you
to be aware of why that patch fixes the bug, why Eric is saying that we
don't need MAX_LEVEL, and why GL is surprisingly difficult to get right.

Patch, as-is, is Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net

On Fri, Jan 9, 2015 at 6:20 PM, Jasper St. Pierre jstpie...@mecheye.net
wrote:

 Well, either MAX_LEVEL / BASE_LEVEL or MIN_FILTER / MAG_FILTER will fix it.

 Basically, a texture is only considered complete [0] when all of its
 usable mipmap levels have been defined. Either you set MAX_LEVEL to say it
 has 0 mipmaps (by default MAX_LEVEL is 1000), or you set MIN_FILTER /
 MAG_FILTER to say it doesn't use any mipmaps when sampling from it.

 Another solution is to use glTexStorage2D to specify the number of mipmaps
 directly when defining internal texture storage.

 [0] See 8.17, TEXTURE COMPLETENESS, in the GL specification:
 https://www.opengl.org/registry/#apispecs

 On Fri, Jan 9, 2015 at 5:39 PM, Keith Packard kei...@keithp.com wrote:

 Axel Davy axel.d...@ens.fr writes:

  Actually we went up with a solution, the final patch wasn't sent to ml
  for a reason
  I don't know or remember.
 
  Recently someone else complaint of the bug and I linked him to a
  preliminary patch we had,
  and it fixed it for him.
  The preliminary patch was
  http://markus.members.selfnet.de/xorg/xwayland.patch
 

 That's this patch:

 diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
 index 54af275..b127b96 100644
 --- a/glamor/glamor_egl.c
 +++ b/glamor/glamor_egl.c
 @@ -170,6 +170,7 @@ glamor_create_texture_from_image(ScreenPtr screen,
  glBindTexture(GL_TEXTURE_2D, *texture);
  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
 +glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 0);

  glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, image);
  glBindTexture(GL_TEXTURE_2D, 0);
 diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
 index 4be883f..7c2bd08 100644
 --- a/hw/xwayland/xwayland-glamor.c
 +++ b/hw/xwayland/xwayland-glamor.c
 @@ -137,6 +137,10 @@ xwl_glamor_create_pixmap_for_bo(ScreenPtr screen,
 struct gbm_bo *bo, int depth)

  glGenTextures(1, xwl_pixmap-texture);
  glBindTexture(GL_TEXTURE_2D, xwl_pixmap-texture);
 +glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
 +glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
 +glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 0);
 +
  glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, xwl_pixmap-image);
  glBindTexture(GL_TEXTURE_2D, 0);

 Eric says that we probably need the MIN_FILTER and MAG_FILTER bits, or
 you'll probably get black, but the MAX_LEVEL changes aren't necessary.

  I think there was a more recent one, but I couldn't find it.

 Let me know.

 --
 -keith

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




 --
   Jasper




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: 1.17 status and schedule

[Jasper St. Pierre]

Markus Wick, the gsoc student on glamor this year.
On Jan 9, 2015 8:16 PM, Keith Packard kei...@keithp.com wrote:

 Jasper St. Pierre jstpie...@mecheye.net writes:

  I guess I should follow up with that I don't really care how the patch
 ends
  up or which six colors of the bikeshed we end up choosing. I just want
 you
  to be aware of why that patch fixes the bug, why Eric is saying that we
  don't need MAX_LEVEL, and why GL is surprisingly difficult to get right.
 
  Patch, as-is, is Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net

 Sounds good. Who wrote it?  We'll need a Signed-off-by: line.

 --
 -keith

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: 1.17 status and schedule

[Jasper St. Pierre]

Well, either MAX_LEVEL / BASE_LEVEL or MIN_FILTER / MAG_FILTER will fix it.

Basically, a texture is only considered complete [0] when all of its usable
mipmap levels have been defined. Either you set MAX_LEVEL to say it has 0
mipmaps (by default MAX_LEVEL is 1000), or you set MIN_FILTER / MAG_FILTER
to say it doesn't use any mipmaps when sampling from it.

Another solution is to use glTexStorage2D to specify the number of mipmaps
directly when defining internal texture storage.

[0] See 8.17, TEXTURE COMPLETENESS, in the GL specification:
https://www.opengl.org/registry/#apispecs

On Fri, Jan 9, 2015 at 5:39 PM, Keith Packard kei...@keithp.com wrote:

 Axel Davy axel.d...@ens.fr writes:

  Actually we went up with a solution, the final patch wasn't sent to ml
  for a reason
  I don't know or remember.
 
  Recently someone else complaint of the bug and I linked him to a
  preliminary patch we had,
  and it fixed it for him.
  The preliminary patch was
  http://markus.members.selfnet.de/xorg/xwayland.patch
 

 That's this patch:

 diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
 index 54af275..b127b96 100644
 --- a/glamor/glamor_egl.c
 +++ b/glamor/glamor_egl.c
 @@ -170,6 +170,7 @@ glamor_create_texture_from_image(ScreenPtr screen,
  glBindTexture(GL_TEXTURE_2D, *texture);
  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
 +glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 0);

  glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, image);
  glBindTexture(GL_TEXTURE_2D, 0);
 diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
 index 4be883f..7c2bd08 100644
 --- a/hw/xwayland/xwayland-glamor.c
 +++ b/hw/xwayland/xwayland-glamor.c
 @@ -137,6 +137,10 @@ xwl_glamor_create_pixmap_for_bo(ScreenPtr screen,
 struct gbm_bo *bo, int depth)

  glGenTextures(1, xwl_pixmap-texture);
  glBindTexture(GL_TEXTURE_2D, xwl_pixmap-texture);
 +glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
 +glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
 +glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 0);
 +
  glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, xwl_pixmap-image);
  glBindTexture(GL_TEXTURE_2D, 0);

 Eric says that we probably need the MIN_FILTER and MAG_FILTER bits, or
 you'll probably get black, but the MAX_LEVEL changes aren't necessary.

  I think there was a more recent one, but I couldn't find it.

 Let me know.

 --
 -keith

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] modesetting: Copy over VRefresh to/from KMS modes

[Jasper St. Pierre]

I mean, if you're going to break the ABI for this, can we fix it so that we
have one mode structure instead of three?

On Thu, Jan 8, 2015 at 4:56 PM, Keith Packard kei...@keithp.com wrote:

 Jasper St. Pierre jstpie...@mecheye.net writes:

  Fine by me. I actually stopped using vrefresh in my kernel driver and
  instead started using drm_mode_vrefresh, so we can actually drop this
  patch.

 Oh, we should send the correct vrefresh value to the kernel; it's part
 of the API after all. Having an integer vrefresh value isn't all that
 useful anyways; we often end up with multiple
 similar-but-not-quite-the-same modes that differ by less than 1Hz in
 vrefresh.

 But, removing VRefresh from the X server and then sending a
 computed value to the kernel seems like a fine plan.

 For now, we need to retain ABI in X, so using your existing plan which
 computes the value to send to the kernel seems appropriate. That just
 needs to be fixed to round the value rather than truncate and I think
 we'll be set for 1.17 at least.

 --
 -keith




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] modesetting: Copy over VRefresh to/from KMS modes

[Jasper St. Pierre]

Fine by me. I actually stopped using vrefresh in my kernel driver and
instead started using drm_mode_vrefresh, so we can actually drop this patch.

On Thu, Jan 8, 2015 at 4:43 PM, Keith Packard kei...@keithp.com wrote:

 Jasper St. Pierre jstpie...@mecheye.net writes:

  Because several functions do not properly fill in mode-VRefresh. A
 simple
  example is xf86RandRModeConvert. I figured it would be easier when we
 fill
  in vrefresh rather than fill all callers.

 Sounds like we should just remove VRefresh then and compute it
 everywhere :-)

 --
 -keith




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] modesetting: Copy over VRefresh to/from KMS modes

[Jasper St. Pierre]

On Thu, Jan 8, 2015 at 2:42 PM, Keith Packard kei...@keithp.com wrote:

 Jasper St. Pierre jstpie...@mecheye.net writes:

  The kernel might want this information during modesetting.
  ---
   hw/xfree86/drivers/modesetting/drmmode_display.c | 2 ++
   1 file changed, 2 insertions(+)
 
  diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
 b/hw/xfree86/drivers/modesetting/drmmode_display.c
  index 824500b..27b7fd8 100644
  --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
  +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
  @@ -145,6 +145,7 @@ drmmode_ConvertFromKMode(ScrnInfoPtr scrn,
   mode-VSyncEnd = kmode-vsync_end;
   mode-VTotal = kmode-vtotal;
   mode-VScan = kmode-vscan;
  +mode-VRefresh = kmode-vrefresh;

 You probably want to compute this using xf86ModeVRefresh instead of just
 using the kernel value as the kernel holds an int while the X server
 makes this a float.

 
   mode-Flags = kmode-flags; // FLAG_BITS;
   mode-name = strdup(kmode-name);
  @@ -174,6 +175,7 @@ drmmode_ConvertToKMode(ScrnInfoPtr scrn,
   kmode-vsync_end = mode-VSyncEnd;
   kmode-vtotal = mode-VTotal;
   kmode-vscan = mode-VScan;
  +kmode-vrefresh = xf86ModeVRefresh(mode);

 Why compute this instead of just pulling from mode-VRefresh?
 And, you'll need to explicitly round this to the nearest int instead of
 truncating.


Because several functions do not properly fill in mode-VRefresh. A simple
example is xf86RandRModeConvert. I figured it would be easier when we fill
in vrefresh rather than fill all callers.


 --
 -keith




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH] modesetting: Copy over VRefresh to/from KMS modes

[Jasper St. Pierre]

The kernel might want this information during modesetting.
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 824500b..27b7fd8 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -145,6 +145,7 @@ drmmode_ConvertFromKMode(ScrnInfoPtr scrn,
 mode-VSyncEnd = kmode-vsync_end;
 mode-VTotal = kmode-vtotal;
 mode-VScan = kmode-vscan;
+mode-VRefresh = kmode-vrefresh;
 
 mode-Flags = kmode-flags; // FLAG_BITS;
 mode-name = strdup(kmode-name);
@@ -174,6 +175,7 @@ drmmode_ConvertToKMode(ScrnInfoPtr scrn,
 kmode-vsync_end = mode-VSyncEnd;
 kmode-vtotal = mode-VTotal;
 kmode-vscan = mode-VScan;
+kmode-vrefresh = xf86ModeVRefresh(mode);
 
 kmode-flags = mode-Flags; // FLAG_BITS;
 if (mode-name)
-- 
2.1.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH] modesetting: Update the cursor without hiding it

[Jasper St. Pierre]

In the new KMS APIs, the legacy drmModeSetCursor ioctl actually waits
for a vblank after changing the cursor image before returning, meaning
that the X server, in attempting to hide the cursor before updating
its image, actually makes that hide *visible* for a full vblank.

It's unknown why the X server does this by default, but turn it off.

If we're with a legacy driver that doesn't support the modern
drmModeSetCursor by waiting for a vblank before returning, we're going
to get a tiny bit of tearing on the cursor plane. But between tearing
with a new cursor image and tearing with a blank cursor image, I'd
rather the former.

The only proper solution to this is an atomic ioctl that page flips
all planes, including the cursor plane, at vblank time and at the same
time.
---
 hw/xfree86/drivers/modesetting/driver.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/xfree86/drivers/modesetting/driver.c 
b/hw/xfree86/drivers/modesetting/driver.c
index 1ebf807..1cb0c7c 100644
--- a/hw/xfree86/drivers/modesetting/driver.c
+++ b/hw/xfree86/drivers/modesetting/driver.c
@@ -1077,6 +1077,7 @@ ScreenInit(ScreenPtr pScreen, int argc, char **argv)
 if (!ms-drmmode.sw_cursor)
 xf86_cursors_init(pScreen, ms-cursor_width, ms-cursor_height,
   HARDWARE_CURSOR_SOURCE_MASK_INTERLEAVE_64 |
+  HARDWARE_CURSOR_UPDATE_UNHIDDEN |
   HARDWARE_CURSOR_ARGB);
 
 /* Must force it before EnterVT, so we are in control of VT and
-- 
2.1.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: misc fixes for VC4

[Jasper St. Pierre]

On Thu, Jan 1, 2015 at 10:31 PM, Keith Packard kei...@keithp.com wrote:

 Rob Clark robdcl...@gmail.com writes:

  What about simply not using GL_QUADS for the normal GL paths?  Is
  using quads, vs tri's and a few extra vertices really going to be a
  win on some other hw?  If not, avoiding quads would be a big help for
  freedreno too..

 Without quads, you end up replicating a lot of vertices, which means a
 lot more data motion from CPU to GPU.


On a UMA system, that's effectively free. With a triangle fan and
glMultiDrawElements, you can get it down to four, same as a quad. Though
I'm not sure if mesa fully supports glMultiDrawElements.

I believe mesa supports primitive reset, so with a triangle fan and
primitive reset, you can get it down to five indices per quad.


  The big performance win, though, is fixing copyarea to give the GL
  information about the area that might be damaged by the operation,
  using the scissor.  Given that it's negative lines of code and not
  significant on i965, I think this is a pretty good idea.  I do wonder
  if we don't want to just always leave scissoring on, like I did to
  logic op.
 
  I'd implemented a similar thing in XA once upon a time... pretty much
  must-have for tilers..

 Do you actually want a closer bounding box on the operation? Given that
 we're likely to have generated a very tight bounds when computing
 damage, I wonder if rejiggering the API to somehow remember that for the
 rendering code could be done?


Yeah, a tight scissor box for rendering would really help.


 --
 -keith

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] modesetting: Fix build with --disable-glamor.

[Jasper St. Pierre]

This is causing build failures on GNOME Continuous:

http://build.gnome.org/continuous/buildmaster/builds/2014/12/31/4/build/log-xorg-xserver.txt

Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net

On Tue, Dec 30, 2014 at 2:58 PM, Eric Anholt e...@anholt.net wrote:

 Kenneth Graunke kenn...@whitecape.org writes:

  present.c: In function 'ms_present_flush':
  present.c:204:9: error: implicit declaration of function
  'glamor_block_handler'

 Reviewed-by: Eric Anholt e...@anholt.net

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [randrproto] spec: Fix RRCrtcGetModes typo

[Jasper St. Pierre]

Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net

On Tue, Oct 28, 2014 at 3:26 AM, Christophe Fergeau cferg...@redhat.com
wrote:

 The correct name is RRCrtcGetInfo.

 Signed-off-by: Christophe Fergeau cferg...@redhat.com
 ---
  randrproto.txt | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/randrproto.txt b/randrproto.txt
 index 864268e..5371eaa 100644
 --- a/randrproto.txt
 +++ b/randrproto.txt
 @@ -929,7 +929,7 @@ dynamic changes in the display environment.

 Errors: Window

 -   RRGetCrtcModes returns information about the current and available
 +   RRGetCrtcInfo returns information about the current and available
 configurations for the specified crtc connected to the screen
 associated with 'window'.

 @@ -1663,7 +1663,7 @@ factors, such as re-cabling a monitor, etc.
 This event is sent whenever the monitor's configuration changes
 or if a new monitor configuration becomes available that was
 not available in the past. In this case, the client MUST call
 -   RRGetCrtcModes to update its view of possible monitor
 +   RRGetCrtcInfo to update its view of possible monitor
 configurations to have a correct view of possible monitor
 organizations.

 --
 2.1.0

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 33/37] composite: Factor out backing store transition

[Jasper St. Pierre]

No? He removed the brace so it's a one-line if body.

On Mon, Oct 27, 2014 at 4:34 PM, Keith Packard kei...@keithp.com wrote:

 Adam Jackson a...@redhat.com writes:

  No functional change.
 
  Signed-off-by: Adam Jackson a...@redhat.com
  ---
   composite/compinit.c | 27 ---
   1 file changed, 16 insertions(+), 11 deletions(-)
 
  diff --git a/composite/compinit.c b/composite/compinit.c
  index 111c16e..7daf171 100644
  --- a/composite/compinit.c
  +++ b/composite/compinit.c
  @@ -104,6 +104,20 @@ compInstallColormap(ColormapPtr pColormap)
   pScreen-InstallColormap = compInstallColormap;
   }
 
  +static void
  +compCheckBackingStore(WindowPtr pWin)
  +{
  +if (pWin-backingStore != NotUseful  !pWin-backStorage) {
  +compRedirectWindow(serverClient, pWin,
 CompositeRedirectAutomatic);
  +pWin-backStorage = TRUE;
  +}
  +else if (pWin-backingStore == NotUseful  pWin-backStorage) {
  +compUnredirectWindow(serverClient, pWin,
  + CompositeRedirectAutomatic);
  +pWin-backStorage = FALSE;
  +}
  +}
  +
   /* Fake backing store via automatic redirection */
   static Bool
   compChangeWindowAttributes(WindowPtr pWin, unsigned long mask)
  @@ -116,17 +130,8 @@ compChangeWindowAttributes(WindowPtr pWin, unsigned
 long mask)
   ret = pScreen-ChangeWindowAttributes(pWin, mask);
 
   if (ret  (mask  CWBackingStore) 
  -pScreen-backingStoreSupport != NotUseful) {
  -if (pWin-backingStore != NotUseful  !pWin-backStorage) {
  -compRedirectWindow(serverClient, pWin,
 CompositeRedirectAutomatic);
  -pWin-backStorage = TRUE;
  -}
  -else if (pWin-backingStore == NotUseful  pWin-backStorage) {
  -compUnredirectWindow(serverClient, pWin,
  - CompositeRedirectAutomatic);
  -pWin-backStorage = FALSE;
  -}
  -}
  +pScreen-backingStoreSupport != NotUseful)
  +compCheckBackingStore(pWin);
 

 Looks like this is missing a } here?

 --
 keith.pack...@intel.com

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Writing a new driver for nested Xorg servers based on Xephyr code

[Jasper St. Pierre]

I don't believe a driver is the correct thing to do. Xorg, in many places,
assumes it's on raw hardware and does things like modesetting and VT
switching, which obviously won't work in a nested environment.

Additionally, I think the Xorg maintainers think that less drivers is
better -- the modesetting driver was recently merged into the X server and
is getting Glamor support for a great out-of-the-box experience that should
work with anything that has EGL support.

The input situation is similar, and is slimming down to just supporting
xf86-input-libinput. Are you going to write an xf86-input-nested as well?

What's the reason you're trying to turn Xorg into a nested server?

On Fri, Sep 26, 2014 at 8:52 AM, Laércio de Sousa 
laercioso...@sme-mogidascruzes.sp.gov.br wrote:

 Hi there!

 Some time ago, I've asked you about current situation of video drivers for
 nested Xorg servers as an alternative to Xephyr. This is mentioned in
 http://www.x.org/wiki/Releases/7.8/

 Currently there's a project named xf86-video-nested, which is written
 somehow independently from Xephyr, but seems no longer maintained.

 Now I've started playing with xf86-video-nested and Xephyr code, trying to
 merge as much code as possible. It's still in an embrionary stage, so I
 want to ask you some questions:

 * Is there an official position from X.Org development team about
 deprecating Xephyr in favour of a driver based approach for nesting Xorg
 server? Or at least let both approaches coexist (maybe moving common code
 to a shared library, as I've asked you previously)?

 * In case I decide to proceed with Xephyr code merging into a video
 driver, should I do it in current project xf86-video-nested, or fork a new
 one (e.g. xf86-video-ephyr)?

 * I'm currently working on mapping Kdrive/Xephyr command line options to
 xorg.conf options for the driver. Which Kdrive/Xephyr options are really
 suitable for this mapping, and which ones are just reimplementations of
 command line options already present in Xorg itself?

 I'm pushing my progress to https://github.com/oiteam/xf86-video-ephyr, if
 you want to take a look. My main motivation with this project is providing
 a suitable way for single-card multiseat configuration on systemd-logind
 based systems, so I'm not so focused on implementing a nested input
 driver at the moment.

 Thanks for your attention!
 --
 *Laércio de Sousa*
 *Orientador de Informática*
 *Escola Municipal Professor Eulálio Gruppi*
 *Rua Ismael da Silva Mello, 559, Mogi Moderno*
 *Mogi das Cruzes - SPCEP 08717-390*
 Telefone: (11) 4726-8313

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: F21/F22: xorg-x11-drv: which for SiS?

[Jasper St. Pierre]

Seems to exist to me:

http://cgit.freedesktop.org/xorg/driver/xf86-video-sis/

On Mon, Sep 22, 2014 at 9:50 PM, Felix Miata mrma...@earthlink.net wrote:

 xorg-x11-drv-sis seems to have disappeared. Did that happen on purpose? It
 still exists as a selelection in Bugzilla. Xorg is looking for sis module
 but
 cannot find it. Gfxchip here is Z7/Z9 (XG20 core). Is it now supposed to be
 using some other (not installed) driver? Before today's upgrade, X still
 worked.
 --
 The wise are known for their understanding, and pleasant
 words are persuasive. Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

 Felix Miata  ***  http://fm.no-ip.com/
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 13/18] dix: Lower backStorage to a bit instead of a pointer

[Jasper St. Pierre]

On Tue, Sep 23, 2014 at 12:32 PM, Adam Jackson a...@redhat.com wrote:

 Signed-off-by: Adam Jackson a...@redhat.com
 ---
  composite/compinit.c | 4 ++--
  dix/window.c | 2 +-
  include/windowstr.h  | 2 +-
  mi/miexpose.c| 2 +-
  4 files changed, 5 insertions(+), 5 deletions(-)

 diff --git a/composite/compinit.c b/composite/compinit.c
 index 48e938f..111c16e 100644
 --- a/composite/compinit.c
 +++ b/composite/compinit.c
 @@ -119,12 +119,12 @@ compChangeWindowAttributes(WindowPtr pWin, unsigned
 long mask)
  pScreen-backingStoreSupport != NotUseful) {
  if (pWin-backingStore != NotUseful  !pWin-backStorage) {
  compRedirectWindow(serverClient, pWin,
 CompositeRedirectAutomatic);
 -pWin-backStorage = (void *) (intptr_t) 1;
 +pWin-backStorage = TRUE;
  }
  else if (pWin-backingStore == NotUseful  pWin-backStorage) {
  compUnredirectWindow(serverClient, pWin,
   CompositeRedirectAutomatic);
 -pWin-backStorage = NULL;
 +pWin-backStorage = FALSE;


Here you use TRUE / FALSE


  }
  }

 diff --git a/dix/window.c b/dix/window.c
 index f227e4c..e1645c3 100644
 --- a/dix/window.c
 +++ b/dix/window.c
 @@ -362,7 +362,7 @@ SetWindowToDefaults(WindowPtr pWin)
  pWin-cursorIsNone = TRUE;

  pWin-backingStore = NotUseful;
 -pWin-backStorage = (void *) NULL;
 +pWin-backStorage = 0;


Here you use 0.


  pWin-mapped = FALSE;   /* off */
  pWin-realized = FALSE; /* off */
 diff --git a/include/windowstr.h b/include/windowstr.h
 index 81f5f8c..740f4a6 100644
 --- a/include/windowstr.h
 +++ b/include/windowstr.h
 @@ -144,12 +144,12 @@ typedef struct _Window {
  Mask eventMask; /* mask from the creating client */
  PixUnion background;
  PixUnion border;
 -void *backStorage;  /* null when BS disabled */
  WindowOptPtr optional;
  unsigned backgroundState:2; /* None, Relative, Pixel, Pixmap */
  unsigned borderIsPixel:1;
  unsigned cursorIsNone:1;/* else real cursor (might inherit) */
  unsigned backingStore:2;
 +unsigned backStorage:1; /* if bs is allocated */
  unsigned saveUnder:1;
  unsigned bitGravity:4;
  unsigned winGravity:4;
 diff --git a/mi/miexpose.c b/mi/miexpose.c
 index 555f3b2..de8ee6c 100644
 --- a/mi/miexpose.c
 +++ b/mi/miexpose.c
 @@ -143,7 +143,7 @@ miHandleExposures(DrawablePtr pSrcDrawable,
 DrawablePtr pDstDrawable,
  if (!pGC-graphicsExposures 
  (pDstDrawable-type == DRAWABLE_PIXMAP) 
  ((pSrcDrawable-type == DRAWABLE_PIXMAP) ||
 - (((WindowPtr) pSrcDrawable)-backStorage == NULL)))
 + (((WindowPtr) pSrcDrawable)-backStorage == 0)))
  return NULL;


Here you use 0.

Why the inconsistency?


  srcBox.x1 = srcx;
 --
 1.9.3

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 17/18] mi: miSlideAndSizeWindow - miResizeWindow

[Jasper St. Pierre]

I sort of like slide because it gives the impression that we copy the
framebuffer contents if the size of the window hasn't changed. That said,
if we want to change this, we should change the name of the slot too.

Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net

On Tue, Sep 23, 2014 at 12:32 PM, Adam Jackson a...@redhat.com wrote:

 Make the function name match the screen slot name.

 Signed-off-by: Adam Jackson a...@redhat.com
 ---
  mi/mi.h| 12 ++--
  mi/miscrinit.c |  2 +-
  mi/miwindow.c  |  5 ++---
  3 files changed, 9 insertions(+), 10 deletions(-)

 diff --git a/mi/mi.h b/mi/mi.h
 index 8cb3ce7..5a455c9 100644
 --- a/mi/mi.h
 +++ b/mi/mi.h
 @@ -470,12 +470,12 @@ extern _X_EXPORT void miMoveWindow(WindowPtr /*pWin
 */ ,
 VTKind   /*kind */
  );

 -extern _X_EXPORT void miSlideAndSizeWindow(WindowPtr /*pWin */ ,
 -   int /*x */ ,
 -   int /*y */ ,
 -   unsigned int /*w */ ,
 -   unsigned int /*h */ ,
 -   WindowPtr/*pSib */
 +extern _X_EXPORT void miResizeWindow(WindowPtr /*pWin */ ,
 + int /*x */ ,
 + int /*y */ ,
 + unsigned int /*w */ ,
 + unsigned int /*h */ ,
 + WindowPtr/*pSib */
  );

  extern _X_EXPORT WindowPtr miGetLayerWindow(WindowPtr   /*pWin */
 diff --git a/mi/miscrinit.c b/mi/miscrinit.c
 index ec4d108..327bd15 100644
 --- a/mi/miscrinit.c
 +++ b/mi/miscrinit.c
 @@ -264,7 +264,7 @@ miScreenInit(ScreenPtr pScreen, void *pbits,  /*
 pointer to screen bits */
  pScreen-MarkWindow = miMarkWindow;
  pScreen-MarkOverlappedWindows = miMarkOverlappedWindows;
  pScreen-MoveWindow = miMoveWindow;
 -pScreen-ResizeWindow = miSlideAndSizeWindow;
 +pScreen-ResizeWindow = miResizeWindow;
  pScreen-GetLayerWindow = miGetLayerWindow;
  pScreen-HandleExposures = miHandleValidateExposures;
  pScreen-ReparentWindow = (ReparentWindowProcPtr) 0;
 diff --git a/mi/miwindow.c b/mi/miwindow.c
 index ba4c9ed..cfe085a 100644
 --- a/mi/miwindow.c
 +++ b/mi/miwindow.c
 @@ -337,9 +337,8 @@ miRecomputeExposures(WindowPtr pWin, void *value)
  }

  void
 -miSlideAndSizeWindow(WindowPtr pWin,
 - int x, int y,
 - unsigned int w, unsigned int h, WindowPtr pSib)
 +miResizeWindow(WindowPtr pWin, int x, int y, unsigned int w, unsigned int
 h,
 +   WindowPtr pSib)
  {
  WindowPtr pParent;
  Bool WasViewable = (Bool) (pWin-viewable);
 --
 1.9.3

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 00/11] Misc window exposure/validation cleanups

[Jasper St. Pierre]

Initial expose happens once. For the xeyes case, doesn't it set a new shape
after it is configured? Setting a new window shape will only re-expose the
parts of the window that weren't in the old shape, right? So the middle of
the eyes won't get exposes, but the circular edges will.

That doesn't sound like it would be too much traffic, and any machine could
handle that nowadays.

On Mon, Sep 22, 2014 at 1:13 PM, Keith Packard kei...@keithp.com wrote:

 Jasper St. Pierre jstpie...@mecheye.net writes:

  Why would xeyes generate a large number of rectangles in a composited
  environment? Are you talking about the initial expose?

 Initial expose or on any resize.

 --
 keith.pack...@intel.com




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libpciaccess] Allow building without O_CLOEXEC

[Jasper St. Pierre]

How old? O_CLOEXEC is part of the 2008 POSIX specification. I really
wouldn't like to build on anything older than that... :(

On Mon, Sep 22, 2014 at 1:24 PM, Aaron Plattner aplatt...@nvidia.com
wrote:

 Old versions of Linux don't support O_CLOEXEC, so rather than failing to
 build,
 allow building without O_CLOEXEC if a new ALLOW_NO_O_CLOEXEC flag is
 defined.

 Create a new helper function, pci_open_cloexec that uses O_CLOEXEC when
 it's
 available and falls back to open + fcntl when it's not.  Route all calls
 to open
 that pass O_CLOEXEC through this new function instead using the following
 Coccinelle patch:

   @@
   expression path, flags;
   @@
   -open(path, flags | O_CLOEXEC)
   +pci_open_cloexec(path, flags)

 Signed-off-by: Aaron Plattner aplatt...@nvidia.com
 ---
 There are three calls to open() that don't use O_CLOEXEC -- are those bugs?

 src/linux_devmem.c:fd = open(/dev/mem, O_RDONLY, 0);
 src/netbsd_pci.c:   fd = open(/dev/ttyE0, O_RDONLY);
 src/netbsd_pci.c:   pcifd = open(netbsd_devname, O_RDWR);

  src/common_vgaarb.c |  2 +-
  src/freebsd_pci.c   | 10 +-
  src/linux_sysfs.c   | 26 +-
  src/netbsd_pci.c|  2 +-
  src/openbsd_pci.c   |  2 +-
  src/pciaccess_private.h | 33 +
  src/solx_devfs.c|  4 ++--
  src/x86_pci.c   |  4 ++--
  8 files changed, 54 insertions(+), 29 deletions(-)

 diff --git a/src/common_vgaarb.c b/src/common_vgaarb.c
 index c59bd788dc5e..f3b523e67c3a 100644
 --- a/src/common_vgaarb.c
 +++ b/src/common_vgaarb.c
 @@ -131,7 +131,7 @@ pci_device_vgaarb_init(void)
  if (!pci_sys)
  return -1;

 -if ((pci_sys-vgaarb_fd = open (/dev/vga_arbiter, O_RDWR |
 O_CLOEXEC))  0) {
 +if ((pci_sys-vgaarb_fd = pci_open_cloexec (/dev/vga_arbiter,
 O_RDWR))  0) {
  return errno;
  }

 diff --git a/src/freebsd_pci.c b/src/freebsd_pci.c
 index 9505a1c17d21..e40d80847bf0 100644
 --- a/src/freebsd_pci.c
 +++ b/src/freebsd_pci.c
 @@ -112,7 +112,7 @@ pci_device_freebsd_map_range(struct pci_device *dev,

  int fd, err = 0;

 -fd = open(/dev/mem, O_RDWR | O_CLOEXEC);
 +fd = pci_open_cloexec(/dev/mem, O_RDWR);
  if (fd == -1)
 return errno;

 @@ -157,7 +157,7 @@ pci_device_freebsd_unmap_range( struct pci_device *dev,
  if ((map-flags  PCI_DEV_MAP_FLAG_CACHABLE) ||
 (map-flags  PCI_DEV_MAP_FLAG_WRITE_COMBINE))
  {
 -   fd = open(/dev/mem, O_RDWR | O_CLOEXEC);
 +   fd = pci_open_cloexec(/dev/mem, O_RDWR);
 if (fd != -1) {
 mrd.mr_base = map-base;
 mrd.mr_len = map-size;
 @@ -297,7 +297,7 @@ pci_device_freebsd_read_rom( struct pci_device * dev,
 void * buffer )
  }

  printf(Using rom_base = 0x%lx\n, (long)rom_base);
 -memfd = open( /dev/mem, O_RDONLY | O_CLOEXEC );
 +memfd = pci_open_cloexec( /dev/mem, O_RDONLY );
  if ( memfd == -1 )
 return errno;

 @@ -574,7 +574,7 @@ pci_device_freebsd_open_legacy_io(struct pci_io_handle
 *ret,
  struct pci_device *dev, pciaddr_t base, pciaddr_t size)
  {
  #if defined(__i386__) || defined(__amd64__)
 -   ret-fd = open(/dev/io, O_RDWR | O_CLOEXEC);
 +   ret-fd = pci_open_cloexec(/dev/io, O_RDWR);

 if (ret-fd  0)
 return NULL;
 @@ -735,7 +735,7 @@ pci_system_freebsd_create( void )
  int i;

  /* Try to open the PCI device */
 -pcidev = open( /dev/pci, O_RDWR | O_CLOEXEC );
 +pcidev = pci_open_cloexec( /dev/pci, O_RDWR );
  if ( pcidev == -1 )
 return ENXIO;

 diff --git a/src/linux_sysfs.c b/src/linux_sysfs.c
 index 08c99719bcba..120cd6411893 100644
 --- a/src/linux_sysfs.c
 +++ b/src/linux_sysfs.c
 @@ -100,7 +100,7 @@ pci_system_linux_sysfs_create( void )
 if ( pci_sys != NULL ) {
 pci_sys-methods =  linux_sysfs_methods;
  #ifdef HAVE_MTRR
 -   pci_sys-mtrr_fd = open(/proc/mtrr, O_WRONLY | O_CLOEXEC);
 +   pci_sys-mtrr_fd = pci_open_cloexec(/proc/mtrr, O_WRONLY);
  #endif
 err = populate_entries(pci_sys);
 }
 @@ -247,7 +247,7 @@ pci_device_linux_sysfs_probe( struct pci_device * dev )
   dev-bus,
   dev-dev,
   dev-func );
 -   fd = open( name, O_RDONLY | O_CLOEXEC);
 +   fd = pci_open_cloexec(name, O_RDONLY);
 if ( fd != -1 ) {
 char * next;
 pciaddr_t  low_addr;
 @@ -309,7 +309,7 @@ pci_device_linux_sysfs_read_rom( struct pci_device *
 dev, void * buffer )
   dev-dev,
   dev-func );

 -fd = open( name, O_RDWR | O_CLOEXEC);
 +fd = pci_open_cloexec(name, O_RDWR);
  if ( fd == -1 ) {
  #ifdef LINUX_ROM
 /* If reading the ROM using sysfs fails, fall back to the old
 @@ -390,7 +390,7 @@ pci_device_linux_sysfs_read( struct pci_device * dev,
 void * data,
   dev-dev,
   dev-func );

 -fd = open( name, O_RDONLY | O_CLOEXEC);
 +

Re: [PATCH 00/11] Misc window exposure/validation cleanups

[Jasper St. Pierre]

Why would xeyes generate a large number of rectangles in a composited
environment? Are you talking about the initial expose?

On Thu, Sep 18, 2014 at 4:49 PM, Keith Packard kei...@keithp.com wrote:

 Adam Jackson a...@redhat.com writes:

  In attempting to get the Always mode of backing store working again, I
  felt the urge to clean the place up a bit.  The most notable change here
  is removing the (questionable) optimization from exposure event
 generation
  to emit a bounding-box event when faced with more than 25 rects in the
  exposed region.  Given that toolkits already coalesce consecutive expose
  boxes, and that you'll never hit it in a composited environment anyway,
  the complexity doesn't seem justified.

 This was written to address shaped windows, which can still generate a
 large number of rectangles, even in a composited environment. I think
 xeyes was the original test case; a full-screen xeyes window has a
 couple thousand rectangles, or about 64kB of data.

 I suspect an xeyes-specific optimization is not all that useful to keep
 around, but I fear that some user somewhere is taking advantage of this...

 --
 keith.pack...@intel.com

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH:libICE] spec: Convert troff \*Q..\*U to DocBook quote.../quote

[Jasper St. Pierre]

Looks good.

Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net

On Sun, Sep 14, 2014 at 2:09 PM, Alan Coopersmith 
alan.coopersm...@oracle.com wrote:

 Reported-by: Jasper St. Pierre jstpie...@mecheye.net
 Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
 ---
  specs/ice.xml |   10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

 diff --git a/specs/ice.xml b/specs/ice.xml
 index 439c2f6..44b7c79 100644
 --- a/specs/ice.xml
 +++ b/specs/ice.xml
 @@ -95,8 +95,8 @@ allow them to share the same transport layer
 connection./para
  paraThrough some mechanism outside ICE, two parties make themselves
 known to
  each other and agree that they would like to communicate using an ICE
  subprotocol.  ICE assumes that this negotation includes some notion by
 which
 -the parties will decide which is the \*Qoriginating\*U party and which is
 -the \*Qanswering\*U party.  The negotiation will also need to provide the
 +the parties will decide which is the quoteoriginating/quote party and
 which is
 +the quoteanswering/quote party.  The negotiation will also need to
 provide the
  originating party with a name or address of the answering party.  Examples
  of mechanisms by which parties can make themselves known to each other are
  the X selection mechanism, environment
 @@ -227,7 +227,7 @@ the initial connection messages; in general data is
 sent in the sender's
  byte order and the receiver is required to swap it appropriately.
  In order to support 64-bit machines, ICE messages
  are padded to multiples of 8 bytes.  All messages are designed so that
 -fields are \*Qnaturally\*U aligned on 16-, 32-, and 64-bit boundaries.
 +fields are quotenaturally/quote aligned on 16-, 32-, and 64-bit
 boundaries.
  The following formula gives the number of bytes necessary
  to pad emphasis remap='I'E/emphasis bytes to the next multiple of
  emphasis remap='I'b/emphasis:/para
 @@ -485,7 +485,7 @@ header and the length field is computed accordingly.
  /para

  para
 -In the following message descriptions, \*QExpected errors\*U indicates
 +In the following message descriptions, quoteExpected errors/quote
 indicates
  errors that may occur in the normal course of events.  Other errors
  (in particular
  functionBadMajor/function
 @@ -1465,7 +1465,7 @@ but it does not affect the existing registration.

  para
  The major opcode specified was already registered.  This is
 -fatal to the \*Qnew\*U protocol being set up by
 +fatal to the quotenew/quote protocol being set up by
  functionProtocolSetup/function but it does not affect the
  existing registration.
  /para
 --
 1.7.9.2

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [Intel-gfx] [PATCH 0/2 xf86-video-intel] Two DRI3/Present bug fixes for UXA

[Jasper St. Pierre]

Why doesn't mesa allocate buffers in the same way for those chips, then?

Do you have any documentation about this?

On Thu, Sep 11, 2014 at 12:37 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:

 On Wed, Sep 10, 2014 at 02:09:07PM -0700, Keith Packard wrote:
   [PATCH 2/2] Correct BO allocation alignment
 
  This patch makes UXA and Mesa agree about how buffers are allocated
  for images. Without this, UXA was requiring larger padding, which
  meant that converting some textures into pixmaps using DRI3 would
  fail.

 That extra alignment is due to gen2 and early gen3 (if
 (!intel-has_relaxed_fencing) covers them).
 -Chris

 --
 Chris Wilson, Intel Open Source Technology Centre
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PULL] hw/xwayland patches

[Jasper St. Pierre]

The following changes since commit 1d32004ed5a3a20b2d5879867e213122dced69d0:

  glamor: Make glyph mask cache per-screen (2014-09-11 18:31:11 -0700)

are available in the git repository at:

  https://github.com/magcius/xserver.git xwayland-work

for you to fetch changes up to 08fabafac8b83ed0de90f9e27aa4b67f604b7e58:

  xwayland: Snap damage reports to the bounding box (2014-09-11 21:47:31
-0600)


Adam Jackson (1):
  xwayland: Snap damage reports to the bounding box

Jasper St. Pierre (2):
  xwayland-input: Fix a crasher for a race with the Wayland compositor
  xwayland: Implement throttling for surfaces based on the frame event

 hw/xwayland/xwayland-input.c |  9 +
 hw/xwayland/xwayland.c   | 48
++--
 hw/xwayland/xwayland.h   |  1 +
 3 files changed, 44 insertions(+), 14 deletions(-)


-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] glamor: sync_fence_set_triggered should use glFlush, not glFinish

[Jasper St. Pierre]

Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net


On Sat, Jul 19, 2014 at 12:48 AM, Keith Packard kei...@keithp.com wrote:

 I intended to use glFlush all along, but somehow managed to type
 glFinish instead. glFlush is sufficient (for a single-queue GPU) to
 ensure serialization between queued rendering in the X server and
 future rendering from the client.

 Signed-off-by: Keith Packard kei...@keithp.com
 ---
  glamor/glamor_sync.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/glamor/glamor_sync.c b/glamor/glamor_sync.c
 index d3d64a9..5e158c3 100644
 --- a/glamor/glamor_sync.c
 +++ b/glamor/glamor_sync.c
 @@ -53,7 +53,7 @@ glamor_sync_fence_set_triggered (SyncFence *fence)

 /* Flush pending rendering operations */
  glamor_make_current(glamor);
 -glFinish();
 +glFlush();

 fence-funcs.SetTriggered = glamor_fence-set_triggered;
 fence-funcs.SetTriggered(fence);
 --
 2.0.1

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] Fix locking bugs with XIAllowTouchEvents() and XIUngrabTouchBegin()

[Jasper St. Pierre]

On Fri, Jul 11, 2014 at 1:54 PM, otay...@redhat.com wrote:

 From: Owen W. Taylor otay...@fishsoup.net

 Fix two places where the display was double locked when an API
 function chained to an implementation that also locks the display.
 ---
  src/XIAllowEvents.c | 6 +-
  src/XIPassiveGrab.c | 1 +
  2 files changed, 2 insertions(+), 5 deletions(-)

 diff --git a/src/XIAllowEvents.c b/src/XIAllowEvents.c
 index c8d997a..b0be6bb 100644
 --- a/src/XIAllowEvents.c
 +++ b/src/XIAllowEvents.c
 @@ -92,11 +92,7 @@ XIAllowTouchEvents(Display *dpy, int deviceid, unsigned
 int touchid,
  LockDisplay(dpy);
  if (_XiCheckExtInit(dpy, XInput_2_2, extinfo) == -1)
 return (NoSuchExtension);
 -
 -status = _XIAllowEvents(dpy, deviceid, event_mode, CurrentTime,
 touchid, grab_window);
 -
  UnlockDisplay(dpy);
 -SyncHandle();

 -return status;
 +return _XIAllowEvents(dpy, deviceid, event_mode, CurrentTime,
 touchid, grab_window);


Shouldn't you remove the declaration for status here?


  }
 diff --git a/src/XIPassiveGrab.c b/src/XIPassiveGrab.c
 index 88f1aff..c743516 100644
 --- a/src/XIPassiveGrab.c
 +++ b/src/XIPassiveGrab.c
 @@ -249,6 +249,7 @@ XIUngrabTouchBegin(Display* display, int deviceid,
 Window grab_window,
  LockDisplay(display);
  if (_XiCheckExtInit(display, XInput_2_2, extinfo) == -1)
 return -1;
 +UnlockDisplay(display);

  return _XIPassiveUngrabDevice(display, deviceid,
 XIGrabtypeTouchBegin, 0,
grab_window, num_modifiers, modifiers);
 --
 1.9.3

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libXi 2/2] XIPassiveGrab: Fix completely broken locking in XIGrabTouchBegin

[Jasper St. Pierre]

_XiCheckExtInit already unlocks the display on error. Yes, it's terrible.


On Wed, Jul 9, 2014 at 3:23 AM, walter harms wha...@bfs.de wrote:



 Am 08.07.2014 23:01, schrieb Jasper St. Pierre:
  _XIPassiveGrabDevice calls LockDisplay as the first thing it does. That
  means that it expects the display to be unlocked. XIGrabTouchBegin locks
  the display to check for the XI extension, and then never unlocks it.
  Effectively, this meant that anybody that called XIGrabTouchBegin after
  XInitThreads just got a deadlock.
 
  Cool.
  ---
   src/XIPassiveGrab.c | 1 +
   1 file changed, 1 insertion(+)
 
  diff --git a/src/XIPassiveGrab.c b/src/XIPassiveGrab.c
  index f3a9924..88f1aff 100644
  --- a/src/XIPassiveGrab.c
  +++ b/src/XIPassiveGrab.c
  @@ -166,6 +166,7 @@ XIGrabTouchBegin(Display *dpy, int deviceid, Window
 grab_window,
   LockDisplay(dpy);
   if (_XiCheckExtInit(dpy, XInput_2_2, extinfo) == -1)
return -1;
  +UnlockDisplay(dpy);
 
   /* FIXME: allow selection of GrabMode for paired devices? */
   return _XIPassiveGrabDevice(dpy, deviceid, XIGrabtypeTouchBegin, 0,


 I am not an expert on this but you should  unlock the display on error
 also.
 I would do it this way:

 LockDisplay(dpy);
 err=_XiCheckExtInit(dpy, XInput_2_2, extinfo);
 UnlockDisplay(dpy);
 if (err == -1)
 return -1;

 jz'ust my 2 cents
 re,
  wh

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libXi 2/2] XIPassiveGrab: Fix completely broken locking in XIGrabTouchBegin

[Jasper St. Pierre]

But all the other existing code that uses _XiCheckExtInit expects it to
unlock on error, but not on success. Peter wrote this code, though, so I'll
let him have the final say.


On Wed, Jul 9, 2014 at 6:31 AM, walter harms wha...@bfs.de wrote:



 Am 09.07.2014 12:23, schrieb Jasper St. Pierre:
  _XiCheckExtInit already unlocks the display on error. Yes, it's terrible.
 
 

 In this case,
 it would be better to move the lock/unlock into _XiCheckExtInit.

 re,
  wh


  On Wed, Jul 9, 2014 at 3:23 AM, walter harms wha...@bfs.de wrote:
 
 
 
  Am 08.07.2014 23:01, schrieb Jasper St. Pierre:
  _XIPassiveGrabDevice calls LockDisplay as the first thing it does. That
  means that it expects the display to be unlocked. XIGrabTouchBegin
 locks
  the display to check for the XI extension, and then never unlocks it.
  Effectively, this meant that anybody that called XIGrabTouchBegin after
  XInitThreads just got a deadlock.
 
  Cool.
  ---
   src/XIPassiveGrab.c | 1 +
   1 file changed, 1 insertion(+)
 
  diff --git a/src/XIPassiveGrab.c b/src/XIPassiveGrab.c
  index f3a9924..88f1aff 100644
  --- a/src/XIPassiveGrab.c
  +++ b/src/XIPassiveGrab.c
  @@ -166,6 +166,7 @@ XIGrabTouchBegin(Display *dpy, int deviceid, Window
  grab_window,
   LockDisplay(dpy);
   if (_XiCheckExtInit(dpy, XInput_2_2, extinfo) == -1)
return -1;
  +UnlockDisplay(dpy);
 
   /* FIXME: allow selection of GrabMode for paired devices? */
   return _XIPassiveGrabDevice(dpy, deviceid, XIGrabtypeTouchBegin,
 0,
 
 
  I am not an expert on this but you should  unlock the display on error
  also.
  I would do it this way:
 
  LockDisplay(dpy);
  err=_XiCheckExtInit(dpy, XInput_2_2, extinfo);
  UnlockDisplay(dpy);
  if (err == -1)
  return -1;
 
  jz'ust my 2 cents
  re,
   wh
 
  ___
  xorg-devel@lists.x.org: X.Org development
  Archives: http://lists.x.org/archives/xorg-devel
  Info: http://lists.x.org/mailman/listinfo/xorg-devel
 
 
 
 




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH libXi 2/2] XIPassiveGrab: Fix completely broken locking in XIGrabTouchBegin

[Jasper St. Pierre]

_XIPassiveGrabDevice calls LockDisplay as the first thing it does. That
means that it expects the display to be unlocked. XIGrabTouchBegin locks
the display to check for the XI extension, and then never unlocks it.
Effectively, this meant that anybody that called XIGrabTouchBegin after
XInitThreads just got a deadlock.

Cool.
---
 src/XIPassiveGrab.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/XIPassiveGrab.c b/src/XIPassiveGrab.c
index f3a9924..88f1aff 100644
--- a/src/XIPassiveGrab.c
+++ b/src/XIPassiveGrab.c
@@ -166,6 +166,7 @@ XIGrabTouchBegin(Display *dpy, int deviceid, Window 
grab_window,
 LockDisplay(dpy);
 if (_XiCheckExtInit(dpy, XInput_2_2, extinfo) == -1)
return -1;
+UnlockDisplay(dpy);
 
 /* FIXME: allow selection of GrabMode for paired devices? */
 return _XIPassiveGrabDevice(dpy, deviceid, XIGrabtypeTouchBegin, 0,
-- 
2.0.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH libXi 1/2] XIPassiveGrab: Fix display locking inside _XIPassiveGrabDevice for error paths

[Jasper St. Pierre]

The code here before would just leave the display locked on error, which
all sorts of broken.
---
 src/XIPassiveGrab.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/XIPassiveGrab.c b/src/XIPassiveGrab.c
index baadccb..f3a9924 100644
--- a/src/XIPassiveGrab.c
+++ b/src/XIPassiveGrab.c
@@ -44,6 +44,7 @@ _XIPassiveGrabDevice(Display* dpy, int deviceid, int 
grabtype, int detail,
 xXIPassiveGrabDeviceReply reply;
 xXIGrabModifierInfo *failed_mods;
 int len = 0, i;
+int ret = -1;
 char *buff;
 
 XExtDisplayInfo *extinfo = XInput_find_display(dpy);
@@ -54,11 +55,11 @@ _XIPassiveGrabDevice(Display* dpy, int deviceid, int 
grabtype, int detail,
 
 if (mask-mask_len  INT_MAX - 3 ||
 (mask-mask_len + 3)/4 = 0x)
-return -1;
+goto out;
 
 buff = calloc(4, (mask-mask_len + 3)/4);
 if (!buff)
-return -1;
+goto out;
 
 GetReq(XIPassiveGrabDevice, req);
 req-reqType = extinfo-codes-major_opcode;
@@ -85,15 +86,11 @@ _XIPassiveGrabDevice(Display* dpy, int deviceid, int 
grabtype, int detail,
 free(buff);
 
 if (!_XReply(dpy, (xReply *)reply, 0, xFalse))
-{
-   UnlockDisplay(dpy);
-   SyncHandle();
-   return -1;
-}
+goto out;
 
 failed_mods = calloc(reply.num_modifiers, sizeof(xXIGrabModifierInfo));
 if (!failed_mods)
-return -1;
+goto out;
 _XRead(dpy, (char*)failed_mods, reply.num_modifiers * 
sizeof(xXIGrabModifierInfo));
 
 for (i = 0; i  reply.num_modifiers  i  num_modifiers; i++)
@@ -103,9 +100,12 @@ _XIPassiveGrabDevice(Display* dpy, int deviceid, int 
grabtype, int detail,
 }
 free(failed_mods);
 
+ret = reply.num_modifiers;
+
+ out:
 UnlockDisplay(dpy);
 SyncHandle();
-return reply.num_modifiers;
+return ret;
 }
 
 int
-- 
2.0.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 2/2] xwayland: Implement throttling for surfaces based on the frame event

[Jasper St. Pierre]

On Wed, Jul 2, 2014 at 2:33 PM, Adam Jackson a...@nwnk.net wrote:

 On Mon, 2014-06-30 at 20:29 -0400, Jasper St. Pierre wrote:
  This implements simple throttling that keeps us to one attach per
  frame. There isn't really an active performance benefit, since the
  buffers will be redrawn only once per frame anyway, but it does cut down
  on the chatty network traffic. Since the Wayland sockets might fill
  up as well, the cut down on the volume of data we send out also provides
  us with a big stability benefit.
 
  Namely, mutter is a lot more stable running gtkperf, a fairly intensive
  X11 application, after this change.

 Not really, no.  Either with or without this change my gnome-on-wayland
 session doesn't survive more than about three consecutive gtkperfs
 before falling over.  (The difference between our scenarios, I suspect,
 being that you have an extra moving part in that you're running mutter
 --wayland under an existing X session where I'm running gnome-shell
 --wayland _as_ my session.)


I was running it natively and couldn't get it to fall down. Hm.


 The issue with this patch, I think, is that instead of drowning the
 wayland server with attaches, we're drowning it in create/destroy pairs
 when gtkperf hits the popup tests.  Which means we actually want to
 defer _all_ window surface activity to the frame event, so that when
 popups live less than a frame time they never even reach xwayland.


That makes a lot more sense, because MapRequest is really the only place
where we're making a synchronous request to the X server as part of
XGetWindowAttributes.

We should implement throttling in X11 for that as well, and I'd be fine
with it, but after talking to Owen a bit more about it, I think we should
probably just go and implement a better buffering approach inside
libwayland-client so that if we ever get EAGAIN when trying to write to the
pipe, we just allocate more data in the internal buffer.


 - ajax


-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH 2/2] xwayland: Implement throttling for surfaces based on the frame event

[Jasper St. Pierre]

This implements simple throttling that keeps us to one attach per
frame. There isn't really an active performance benefit, since the
buffers will be redrawn only once per frame anyway, but it does cut down
on the chatty network traffic. Since the Wayland sockets might fill
up as well, the cut down on the volume of data we send out also provides
us with a big stability benefit.

Namely, mutter is a lot more stable running gtkperf, a fairly intensive
X11 application, after this change.
---
 hw/xwayland/xwayland.c | 35 ++-
 hw/xwayland/xwayland.h |  1 +
 2 files changed, 31 insertions(+), 5 deletions(-)

diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 17b7bf7..e0ae2a9 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -308,6 +308,9 @@ xwl_unrealize_window(WindowPtr window)
 xorg_list_del(xwl_window-link_damage);
 DamageUnregister(xwl_window-damage);
 DamageDestroy(xwl_window-damage);
+if (xwl_window-frame_callback)
+wl_callback_destroy(xwl_window-frame_callback);
+
 free(xwl_window);
 dixSetPrivate(window-devPrivates, xwl_window_private_key, NULL);
 
@@ -321,17 +324,35 @@ xwl_save_screen(ScreenPtr pScreen, int on)
 }
 
 static void
+frame_callback(void *data,
+   struct wl_callback *callback,
+   uint32_t time)
+{
+struct xwl_window *xwl_window = data;
+xwl_window-frame_callback = NULL;
+}
+
+static const struct wl_callback_listener frame_listener = {
+frame_callback
+};
+
+static void
 xwl_screen_post_damage(struct xwl_screen *xwl_screen)
 {
-struct xwl_window *xwl_window;
+struct xwl_window *xwl_window, *next_xwl_window;
 RegionPtr region;
 BoxPtr box;
 int count, i;
 struct wl_buffer *buffer;
 PixmapPtr pixmap;
 
-xorg_list_for_each_entry(xwl_window, xwl_screen-damage_window_list,
- link_damage) {
+xorg_list_for_each_entry_safe(xwl_window, next_xwl_window,
+  xwl_screen-damage_window_list, 
link_damage) {
+/* If we're waiting on a frame callback from the server,
+ * don't attach a new buffer. */
+if (xwl_window-frame_callback)
+continue;
+
 region = DamageRegion(xwl_window-damage);
 count = RegionNumRects(region);
 
@@ -351,11 +372,15 @@ xwl_screen_post_damage(struct xwl_screen *xwl_screen)
   box-x1, box-y1,
   box-x2 - box-x1, box-y2 - box-y1);
 }
+
+xwl_window-frame_callback = wl_surface_frame(xwl_window-surface);
+wl_callback_add_listener(xwl_window-frame_callback, frame_listener, 
xwl_window);
+
 wl_surface_commit(xwl_window-surface);
 DamageEmpty(xwl_window-damage);
-}
 
-xorg_list_init(xwl_screen-damage_window_list);
+xorg_list_del(xwl_window-link_damage);
+}
 }
 
 static void
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index fc68550..51ed8d8 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -103,6 +103,7 @@ struct xwl_window {
 WindowPtr window;
 DamagePtr damage;
 struct xorg_list link_damage;
+struct wl_callback *frame_callback;
 };
 
 #define MODIFIER_META 0x01
-- 
2.0.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH 1/2] xwayland-input: Fix a crasher for a race with the Wayland compositor

[Jasper St. Pierre]

If something quickly maps and unmaps a window, then we'll immediately
create and destroy the Wayland surface that cooresponds to that
window. If our mouse pointer is over the window when the surface is
created, we'll receive a enter on the window.

Since resource creation and destruction is not synchronous, that
means that the compositor will queue up an event for a resource that's
eventually destroyed. On the client-side, when we receive this message,
we note that the resource isn't allocated, and get a NULL surface in our
enter handler. We immediately try to dereference this, and then crash.

This was caused by running gtkperf while moving the window a lot.
---
 hw/xwayland/xwayland-input.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index 990cb82..469ef25 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -152,6 +152,15 @@ pointer_handle_enter(void *data, struct wl_pointer 
*pointer,
 ScreenPtr pScreen = xwl_seat-xwl_screen-screen;
 ValuatorMask mask;
 
+/* There's a race here where if we create and then immediately
+ * destroy a surface, we might end up in a state where the Wayland
+ * compositor sends us an event for a surface that doesn't exist.
+ *
+ * Don't process enter events in this case.
+ */
+if (surface == NULL)
+return;
+
 xwl_seat-xwl_screen-serial = serial;
 xwl_seat-pointer_enter_serial = serial;
 
-- 
2.0.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: xserver dependency on crypto library because of a hashmap

[Jasper St. Pierre]

Nevertheless, SHA-1 is a cryptographic hash function and an extremely poor
choice for hash tables. Have we considered using the classic djb2 instead?
On Jun 8, 2014 5:37 PM, Rémi Cardona r...@gentoo.org wrote:

 Le dimanche 08 juin 2014 à 15:46 +0200, Marek Behun a écrit :
  300 lines of code only to
  wrap external library calls. In those 300 lines one could write some
  simpler, faster hashmap hash function (isn't crc32 or something simpler
  good enough for this?),

 Back in our bugzilla, your only concern seemed to be about our package
 depending on OpenSSL. While I understand that concern with all the
 recent security flaws in that lib, do you have any numbers to back your
 new-found concern regarding speed?

 As for using something else, SHA1 was introduced nearly 7 years ago,
 precisely to replace a custom XOR hash:

 commit 19b3b1fd8feb343a690331cafe88ef10b34b9d98
 Author: Carl Worth cwo...@cworth.org
 Date:   Tue Jul 31 17:04:13 2007 -0700

 See this thread for some reasoning
 http://lists.x.org/archives/xorg/2007-August/026730.html

  or one could copy the entire code for sha1 from another library.

 commit a39377cbcbd3091095efbeab25bec18ae520147e
 Author: Keith Packard kei...@keithp.com
 Date:   Tue Sep 23 09:22:07 2008 -0700

 Revert Render: Use built-in SHA1 library

 This reverts commit d3bd31fddff7894f89ba80a3cdddff49aff08db8.

 X.org should not be providing a custom SHA1 implementation.

 Bundled libraries are distributions' worst nightmares and this
 particular debate has been settled.

  Depending on external crypto library because of a hashmap is insane for
  Christ's sake.

 I fail to see the insanity of depending on other libraries when they fit
 the bill.

 Rémi

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Alternative approach for a nested-xserver based video driver

[Jasper St. Pierre]

And on the other side, you have people like me who simply want to replace
all video drivers with -modesetting, and all input drivers with libinput :)


On Wed, Jun 4, 2014 at 12:16 PM, Jamey Sharp ja...@minilop.net wrote:

 On Wed, Jun 04, 2014 at 09:07:22AM -0300, Laércio de Sousa wrote:
  Hello there!
 
  Some time ago I've wrotten asking for current status of xf86-video-nested
  development. I believe that, for a more robust single-card multiseat
 setup
  with systemd-logind, a real Xorg server with some kind of nested video
  driver works better than Xephyr, since it still lacks proper input
  hotplugging, for example.
 
  On the other hand, xf86-video-nested have received no relevant
 improvements
  for years, while Xephyr graphics support development is quite active.

 Wow, I can't believe that capstone project was almost three years ago
 already.

  So I'm thinking on rewriting xf86-video-nested driver based on latest
  Xephyr code. A more ambicious idea is to identify and move all video
  related code that could be useful for both Xephyr and nested driver to a
  shared library, namely libephyr, and link them against it. We could
 even
  rename xf86-video-nested to xf86-video-ephyr to reflect the new approach.
 
  I have absolutely no experience in writing video drivers for Xorg, but
 I'm
  open for learning. Any feedback from you will be welcome.

 In my opinion, this would be great. One of my long-term goals is to have
 only one X server implementation that anyone cares about, so being able
 to replace both Xnest and Xephyr with Xorg+video-ephyr sounds good to
 me. (And ideally, Xdmx would die in a fire.)

 If I had my way, you wouldn't need to build a shared library, because
 you'd just replace Xephyr. But practicality suggests that your shared
 library plan is a better migration strategy.

 I might suggest that you try hacking stuff into video-nested by
 copy-paste before you try to figure out what shared library API you
 need, though. It's much easier to make progress through incrementally
 testable changes.

 I hope this helps. :-)
 Jamey

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] configure: Require sufficiently new wayland-client for xwayland ddx

[Jasper St. Pierre]

I'd prefer it if we got an updated and working Xwayland like rawhide has,
but better error messages are always appreciated.

Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net


On Mon, Jun 2, 2014 at 1:32 PM, Adam Jackson a...@nwnk.net wrote:

 On Wed, 2014-05-21 at 09:22 -0400, Adam Jackson wrote:
  The explicit release requests were added in 1.3.0, don't try to build
  against older.

 Ping?  Fedora 20 includes 1.2.0 so I keep running into this.  (Yes
 probably we should update that, but.)

 - ajax

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Xorg copyright infrigement

[Jasper St. Pierre]

The VESA CVT standard is still free, by the way. You can find download
instructions for accessing any VESA public standard here:

http://www.vesa.org/wp-content/uploads/2010/12/thankspublic.htm


On Mon, Apr 28, 2014 at 5:08 AM, Egbert Eich e...@freedesktop.org wrote:

 On Sun, Apr 27, 2014 at 12:28:46PM +0200, Mateusz Jończyk wrote:
  
   The xls however, felt as if it was meant as a reference
 implementation, aimed at
   improving the proliferation of CVT. If graham does get contacted, i
 think he
   would agree.
  I don't have any doubts that the Authors of the XLS would agree to
 inclusion of its
  derivative works in XOrg and other programs.
  Until that happens, however, we cannot rely on it.
  
   Now, before we do get access to those documents, how are you intending
 to
   circumvent this claimed copyright infringement without infringing
 yourself under
   your very strict rules?
  We could just rewrite it using the Chinese wall principle:
  http://en.wikipedia.org/wiki/Clean_room_design

 Gentlemen - please get out of this rat hole!

 The implemenation in the X.Org repo - from which other implemenations
 were derived - is not a copy of the code in the spread sheet and
 therefore does not infringe on any copyright held by the author of it:
 the spread sheet is in XLS, the X.Org implemenation is C code:
 The *only* thing in common with the spread sheet is the *algorithm*.

 This algorithm however is a published and publically available VESA
 standard.

 One can obtain VESA standards either
 - by downloading them if they are available for free download (some are)
 - by purchasing them
 - by being a member of VESA.

 The beauty of VESA standards is that they are royalty free: Once one
 has obtained one one can freely implement it.
 In our case here, the algorithm if the CVT standard was published by
 VESA and made available for free download thru the said spread sheet
 (instead of a pdf document).

 So why on earth would anybody now want to do a clean room implemenation
 of a standard that is publically available?

 The *only* thing that should be done is to get rid of the paragraph
 containing the eye-brow raiser term 'stolen' to something saying:

 This code is an implemenation of the VESA CVT standard.
 This standard can be obtained from http://www.vesa.org.

 Cheers,
 Egbert.

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Xorg copyright infrigement

[Jasper St. Pierre]

On Sun, Apr 27, 2014 at 6:28 AM, Mateusz Jończyk mat.jonc...@o2.pl wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello,

 W dniu 27.04.2014 11:33, Luc Verhaegen pisze:
  Thanks so very much for taking me in CC.
 Right, I should have CC You. Please excuse me. I am new to this project.

 
  I am quite certain that if i hadn't mentioned the origins of these
 calculations,
  you would never have bothered.
 Yep, that would be probably lost and forgotten.
  I amazed that you bother now, now that it spread to a buzzword project.
 Somebody simply noticed the fact of possible copyright problems here.
 
  I clearly explained the origins for a reason: namely so that we could
 update our
  code to match in the unlikely case some changes happen, i even explained
 that
  reasoning.
 
  CVT is a VESA standard. I did not and do not have access to VESA
 documents, and
  the dog ate the Xorg boards homework, as noone seems to remember what
 happened
  to the Xorg VESA membership. My feeling however is that this spreadsheet
 is a
  rather direct implementation of the VESA standard, and that if the Xorg
 board
  gets its act together (for a change), we will actually be able to verify
 where
  this information originally came from.
 
  The xls however, felt as if it was meant as a reference implementation,
 aimed at
  improving the proliferation of CVT. If graham does get contacted, i
 think he
  would agree.
 I don't have any doubts that the Authors of the XLS would agree to
 inclusion of its
 derivative works in XOrg and other programs.
 Until that happens, however, we cannot rely on it.
 
  Now, before we do get access to those documents, how are you intending to
  circumvent this claimed copyright infringement without infringing
 yourself under
  your very strict rules?
 We could just rewrite it using the Chinese wall principle:
 http://en.wikipedia.org/wiki/Clean_room_design


Patches welcome.


  Luc Verhaegen.
 

 - --
 Pozdrawiam,
 Mateusz Jończyk
 AEI, Informatyka, Semestr 2 Magisterskich, BDiIS

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 Comment: My public key: 0x2C64C488 on hkp://pool.sks-keyservers.net
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQEcBAEBAgAGBQJTXNvXAAoJELLT9LcsZMSI+WkIAIqQPwI/D1LPudUOFygjmnPq
 fBMmm7i8f1H7InVRHHavLN8hSGl3XddyKvu1ZTBbEyR8jXFwFElykxFRaGG7RxYs
 MWJyz+/f4FYbpRx0xm17QIQr9dfxvHbtStIsiTR4ZuVU0FdB40wQp73ZI/D1EPa5
 y33pjR3ivkbISGPDFDGyueXzdBHW7Sd5gszTTfyh1Pn3Se2L2cEsWPdmIEQXPO5l
 tz6i75qOCy+D2UrXNZT9LTbA/lxo5r6WQl9XtnYANAoibgkwz/H8fvHu4DgS5a//
 crNyPLd+my0mzEcdxezpKzGpnGtxZe1W3tTKDMZRDjXQ1bnRtrIuonNgQrUdljc=
 =EsiA
 -END PGP SIGNATURE-
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] Add a command line argument for disabling indirect GLX.

[Jasper St. Pierre]

I'd be surprised if pretty much any GL application works using the indirect
GLX extension. It's only specified up to GL 1.4, which was released over 12
years ago.


On Thu, Apr 24, 2014 at 9:32 AM, James Cloos cl...@jhcloos.com wrote:

 Does preventing indirect glx prevent glx over x over tcp?

 (Not a criticism of the patch; I don't remember whether direct is
 possible w/o shared mem.)

 -JimC
 --
 James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH] dixfonts: Turn a missing directory ErrorF into a DebugF

[Jasper St. Pierre]

On systems without these directories, we don't need to be complaining
loudly.

Reviewed-by: Kristian Hoegsberg k...@bitplanet.net
---
 dix/dixfonts.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dix/dixfonts.c b/dix/dixfonts.c
index 83d2539..1c6442c 100644
--- a/dix/dixfonts.c
+++ b/dix/dixfonts.c
@@ -1658,7 +1658,7 @@ SetFontPathElements(int npaths, unsigned char *paths, int 
*bad, Bool persist)
 err = (*fpe_functions[fpe-type].init_fpe) (fpe);
 if (err != Successful) {
 if (persist) {
-ErrorF
+DebugF
 ([dix] Could not init font path element %s, 
removing from list!\n,
  fpe-name);
 }
-- 
1.9.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libXfont] Fix buffer read overrun

[Jasper St. Pierre]

Always using strlen(s); should be fine. The compiler will optimize it out
for a literal string anyway.


On Fri, Apr 18, 2014 at 4:39 PM, Keith Packard kei...@keithp.com wrote:

 Alan Coopersmith alan.coopersm...@oracle.com writes:

  They work, as long as you only ever pass a literal string to them, not a
  pointer.

 Right, but there's no type safety in that.

  Seems like a reasonable simplification in the server - hard to use from
 other
  modules (libXfont, drivers, etc.) until you're sure you'll only ever be
 used
  with a server recognizing that.

 So, presumably a macro in some convenient header file would still be
 useful for external consumers.

 --
 keith.pack...@intel.com

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [BUG] Window resizing broken

[Jasper St. Pierre]

Resizing by window borders is a WM operation, is it not? What WM are you
using, and does it work on other WMs?


On Mon, Apr 7, 2014 at 2:56 AM, Knut Petersen knut_peter...@t-online.dewrote:

 Hi everybody:

 Problem: Resizing of windows is broken as it is impossible to grab a
 window border.

 Broken version:
 full xorg git master build, 5. Apr 16:26, xserver git
 901fbfbbbd71c0d8208095...

 Known good version:
 full xorg git master build, 22. Mar 17:13, xserver git
 4fb31e4824d46edc80bb49b ...

 System:
 openSuSE 13.1 with kernel 3.13.9 and 3.14.0, Xorg git builds, AOpen
 i915GMm-hfs motherboard with Pentium M Dothan cpu

 Reproducibility: 100%

 Is this a known problem?

 If not: Bisecting required?

 cu,
  Knut
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 2/7] composite: Add exception mechanism for implicit redirection policy

[Jasper St. Pierre]

Does this mean this mean that reparenting an RGB24 visual window into an
ARGB32 visual window will only be copy-free on Xwayland and not Xorg?


On Tue, Apr 1, 2014 at 2:53 AM, Kristian Høgsberg k...@bitplanet.net wrote:

 Normally composite will decide to add implicit redirection when a
 window with an alternate visual is a parent of a window with a regular
 visual or vice versa.  This uses extra pixmap memory and incurs an extra
 copy.  This exception mechanism provides a way for a DDX to override this
 if the DDX knows that its acceleration architecture will render correctly.

 The relevant case is that of an RGB window reparented into a ARGB parent
 frame window.  If the DDX knows that the acceleration architecture in use
 will pad the alpha channel to opaque when rendering to the RGB window,
 the implicit redirection can be avoided.

 This patch adds a new composite function:

   CompositeRegisterImplicitRedirectionException()

 which lets a DDX register a pair of parent and child window visuals, that
 will not be implicitly redirected even if the normal policy would have
 made that choice.

 Signed-off-by: Kristian Høgsberg k...@bitplanet.net
 Reviewed-by: Keith Packard kei...@keithp.com
 ---
  composite/compinit.c | 24 
  composite/compint.h  |  7 +++
  composite/compositeext.h |  4 
  composite/compwindow.c   | 18 ++
  4 files changed, 53 insertions(+)

 diff --git a/composite/compinit.c b/composite/compinit.c
 index 1db9e0b..48e938f 100644
 --- a/composite/compinit.c
 +++ b/composite/compinit.c
 @@ -229,6 +229,28 @@ CompositeRegisterAlternateVisuals(ScreenPtr pScreen,
 VisualID * vids,
  return compRegisterAlternateVisuals(cs, vids, nVisuals);
  }

 +Bool
 +CompositeRegisterImplicitRedirectionException(ScreenPtr pScreen,
 +  VisualID parentVisual,
 +  VisualID winVisual)
 +{
 +CompScreenPtr cs = GetCompScreen(pScreen);
 +CompImplicitRedirectException *p;
 +
 +p = realloc(cs-implicitRedirectExceptions,
 +sizeof(p[0]) * (cs-numImplicitRedirectExceptions + 1));
 +if (p == NULL)
 +return FALSE;
 +
 +p[cs-numImplicitRedirectExceptions].parentVisual = parentVisual;
 +p[cs-numImplicitRedirectExceptions].winVisual = winVisual;
 +
 +cs-implicitRedirectExceptions = p;
 +cs-numImplicitRedirectExceptions++;
 +
 +return TRUE;
 +}
 +
  typedef struct _alternateVisual {
  int depth;
  CARD32 format;
 @@ -349,6 +371,8 @@ compScreenInit(ScreenPtr pScreen)

  cs-numAlternateVisuals = 0;
  cs-alternateVisuals = NULL;
 +cs-numImplicitRedirectExceptions = 0;
 +cs-implicitRedirectExceptions = NULL;

  if (!compAddAlternateVisuals(pScreen, cs)) {
  free(cs);
 diff --git a/composite/compint.h b/composite/compint.h
 index 12dc8b3..56b76c5 100644
 --- a/composite/compint.h
 +++ b/composite/compint.h
 @@ -119,6 +119,11 @@ typedef struct _CompOverlayClientRec {
  XID resource;
  } CompOverlayClientRec;

 +typedef struct _CompImplicitRedirectException {
 +XID parentVisual;
 +XID winVisual;
 +} CompImplicitRedirectException;
 +
  typedef struct _CompScreen {
  PositionWindowProcPtr PositionWindow;
  CopyWindowProcPtr CopyWindow;
 @@ -155,6 +160,8 @@ typedef struct _CompScreen {
  CloseScreenProcPtr CloseScreen;
  int numAlternateVisuals;
  VisualID *alternateVisuals;
 +int numImplicitRedirectExceptions;
 +CompImplicitRedirectException *implicitRedirectExceptions;

  WindowPtr pOverlayWin;
  Window overlayWid;
 diff --git a/composite/compositeext.h b/composite/compositeext.h
 index 0b148f0..b96cb1d 100644
 --- a/composite/compositeext.h
 +++ b/composite/compositeext.h
 @@ -35,6 +35,10 @@ extern _X_EXPORT Bool
 CompositeRegisterAlternateVisuals(ScreenPtr pScreen,
  VisualID * vids,
  int nVisuals);

 +extern _X_EXPORT Bool
 CompositeRegisterImplicitRedirectionException(ScreenPtr pScreen,
 +
  VisualID parentVisual,
 +
  VisualID winVisual);
 +
  extern _X_EXPORT RESTYPE CompositeClientWindowType;

  #endif  /* _COMPOSITEEXT_H_ */
 diff --git a/composite/compwindow.c b/composite/compwindow.c
 index 6c24349..8824294 100644
 --- a/composite/compwindow.c
 +++ b/composite/compwindow.c
 @@ -336,6 +336,21 @@ compIsAlternateVisual(ScreenPtr pScreen, XID visual)
  }

  static Bool
 +compIsImplicitRedirectException(ScreenPtr pScreen,
 +XID parentVisual, XID winVisual)
 +{
 +CompScreenPtr cs = GetCompScreen(pScreen);
 +int i;
 +
 +for (i = 0; i  cs-numImplicitRedirectExceptions; i++)
 +if (cs-implicitRedirectExceptions[i].parentVisual ==
 parentVisual 
 +cs-implicitRedirectExceptions[i].winVisual == winVisual)
 +return TRUE;
 +
 +return 

Re: [PATCH v2 2/2] xf86LogInit: log to XDG_DATA_HOME when not running as root

[Jasper St. Pierre]

It seems to me like they should be in ~/.cache/, which is where
non-important files that are mostly transient should go.


On Wed, Mar 26, 2014 at 10:15 AM, Hans de Goede hdego...@redhat.com wrote:

 Hi,

 On 03/26/2014 12:51 PM, Mark Kettenis wrote:
  From: Hans de Goede hdego...@redhat.com
  Date: Wed, 26 Mar 2014 12:24:50 +0100
 
  When no logfile was specified (xf86LogFileFrom == X_DEFAULT) and
  we're not running as root log to $XDG_DATA_HOME/xorg/Xorg.#.log as
  Xorg won't be able to log to the default /var/log/... when it is not
  running as root.
 
  Having log files in .../share/... feels wrong.

 I know, but if we want to stick to the XDG guidelines for this (which I
 say we do), this is where they are supposed to go.

 Regards,

 Hans
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xinit 2/3] startx: Under Linux start X on the current VT

[Jasper St. Pierre]

On Tue, Mar 25, 2014 at 10:02 AM, Hans de Goede hdego...@redhat.com wrote:

 Hi,

 On 03/25/2014 02:50 PM, Julien Cristau wrote:
  On Tue, Mar 25, 2014 at 12:56:35 +0100, Hans de Goede wrote:
 
  When we let X allocate a new VT, systemd-logind will not recognize any
  processes running on this VT as belonging to a valid session (since
 there
  was no pam session opened on that tty).
 
  This causes problems like PolicyKit denials for these processes.
 
  ConsoleKit under Linux has been deprecated for a few years now and is no
  longer being maintained, so simply make this the default under Linux.
 
  That sounds like a bad idea.  If people want policykit to be happy, they
  should just use a display manager, IMO.

 Well people disagree:
 https://bugzilla.redhat.com/show_bug.cgi?id=806491


From http://cgit.freedesktop.org/xorg/app/xinit/tree/startx.cpp:

XCOMM This is just a sample implementation of a slightly less primitive
XCOMM interface than xinit.  It looks for user .xinitrc and .xserverrc
XCOMM files, then system xinitrc and xserverrc files, else lets xinit choose
XCOMM its default.  The system xinitrc should probably do things like check
XCOMM for .Xresources files and merge them in, start up a window manager,
XCOMM and pop a clock and several xterms.
XCOMM
XCOMM Site administrators are STRONGLY urged to write nicer versions.

I assume we can't tell people who are still using startx in 2014 to just
stop using it?

 Sharing a VT between X and something else smells like trouble.

 It is not shared, X simply takes over the VT until startx exits again,
 and we've been doing this in Fedora for years without issues.

 Regards,

 Hans
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 15/20] glamor: Provide a placeholder for glamor_pushpixels

[Jasper St. Pierre]

On Thu, Mar 20, 2014 at 7:23 PM, Eric Anholt e...@anholt.net wrote:

 Keith Packard kei...@keithp.com writes:

  This just calls miPushPixels until glamor uses FBOs for bitmaps

 The only cases that PushPixels() is called that I can find:

 - miglblt.c

 We're doing hand-accelerated glyph blits, so that's gone.

 - miarc.c

 I tried a few likely x11perfs and nothing hit it.  Eventually I came up
 with
 on -wpcircle100 -rop GXnand, and this patch was 1.5% faster while
 removing apparent rendering bugs.


I'd imagine that's hit by anything using XDrawArc. Surprisingly, there's
not many applications using it out there.

Most of what I found by Googling and using code search was example code. In
fact, the only uses I could find of it were in Guy Keren's Basic Graphics
Programming With The Xlib Library and O'Reilly's XLIB Programming Manual.

Things like xclock / oclock seem to use XFillArc twice to stroke an arc or
circle rather than use XDrawArc.


 - midispur.c

 I don't think this is a thing we're worried about.

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH synaptics] man: setting scroll deltas to 0 doesn't work (#75074)

[Jasper St. Pierre]

Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net


On Mon, Feb 17, 2014 at 7:17 PM, Peter Hutterer peter.hutte...@who-t.netwrote:

 6d47d33 disallows a zero value for horizontal/vertical scroll deltas but
 the
 man page wasn't updated. We've added separate toggles to enable/disable
 scrolling a few years ago, setting the distance to 0 is not recommended.

 X.Org Bug 75074 http://bugs.freedesktop.org/show_bug.cgi?id=75074

 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
 ---
  man/synaptics.man | 3 ---
  1 file changed, 3 deletions(-)

 diff --git a/man/synaptics.man b/man/synaptics.man
 index eb04eb2..7da7527 100644
 --- a/man/synaptics.man
 +++ b/man/synaptics.man
 @@ -585,9 +585,6 @@ effect on scrolling speed.
  Scrolling speed is determined solely from the VertScrollDelta and
  HorizScrollDelta parameters.
  .
 -To disable vertical or horizontal scrolling, set VertScrollDelta or
 -HorizScrollDelta to zero.
 -.
  To invert the direction of vertical or horizontal scrolling, set
  VertScrollDelta or HorizScrollDelta to a negative value.
  .
 --
 1.8.4.2

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH:mkcomposecache] Replace manual calculations of memory allocations with asprintf calls

[Jasper St. Pierre]

I didn't know asprintf was standardized. Nice to hear it!

Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net


On Wed, Feb 19, 2014 at 1:23 AM, Alan Coopersmith 
alan.coopersm...@oracle.com wrote:

 Includes fallback asprintf() for pre-Unix08 platforms

 Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
 ---
  configure.ac |7 +-
  mkcomposecache.c |   66
 +-
  2 files changed, 61 insertions(+), 12 deletions(-)

 diff --git a/configure.ac b/configure.ac
 index 727f100..aff0a49 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -8,6 +8,11 @@ AC_CONFIG_HEADERS([config.h])
  AM_INIT_AUTOMAKE([foreign dist-bzip2])
  AM_MAINTAINER_MODE

 +# Set common system defines for POSIX extensions, such as _GNU_SOURCE
 +# Must be called before any macros that run the compiler (like those in
 +# XORG_DEFAULT_OPTIONS) to avoid autoconf errors.
 +AC_USE_SYSTEM_EXTENSIONS
 +
  # Require X.Org macros 1.8 or later for MAN_SUBSTS set by
 XORG_MANPAGE_SECTIONS
  m4_ifndef([XORG_MACROS_VERSION],
[m4_fatal([must install xorg-macros 1.8 or later before running
 autoconf/autogen])])
 @@ -18,7 +23,7 @@ PKG_CHECK_MODULES(XLIB, x11)

  AC_CHECK_HEADERS([stdio.h stdlib.h string.h unistd.h locale.h], ,
 [AC_MSG_FAILURE(cannot find essential header)])
  AC_CHECK_FUNCS([setlocale], , [AC_MSG_FAILURE(cannot find essential
 function)])
 -AC_CHECK_FUNCS([unsetenv])
 +AC_CHECK_FUNCS([unsetenv asprintf])

  AC_CONFIG_FILES([
 Makefile
 diff --git a/mkcomposecache.c b/mkcomposecache.c
 index c65951c..3b94e77 100644
 --- a/mkcomposecache.c
 +++ b/mkcomposecache.c
 @@ -27,11 +27,55 @@
  #include unistd.h
  #include locale.h

 +#ifndef HAVE_ASPRINTF
 +#include stdarg.h
 +
 +/* sprintf variant found in newer libc's which allocates string to print
 to */
 +static int _X_ATTRIBUTE_PRINTF(2,3)
 +asprintf(char ** ret, const char *format, ...)
 +{
 +char buf[256];
 +int len;
 +va_list ap;
 +
 +va_start(ap, format);
 +len = vsnprintf(buf, sizeof(buf), format, ap);
 +va_end(ap);
 +
 +if (len  0)
 +   return -1;
 +
 +if (len  sizeof(buf))
 +{
 +   *ret = strdup(buf);
 +}
 +else
 +{
 +   *ret = malloc(len + 1); /* vsnprintf doesn't count trailing '\0' */
 +   if (*ret != NULL)
 +   {
 +   va_start(ap, format);
 +   len = vsnprintf(*ret, len + 1, format, ap);
 +   va_end(ap);
 +   if (len  0) {
 +   free(*ret);
 +   *ret = NULL;
 +   }
 +   }
 +}
 +
 +if (*ret == NULL)
 +   return -1;
 +
 +return len;
 +}
 +#endif /* HAVE_ASPRINTF */
 +
  int main (int argc, char *argv[]) {
  Display *disp;
  XIM  im;
  char*src, *dest;
 -int  len;
 +int  ret;

  if (argc != 4  argc != 5) {
 fprintf (stderr, Usage: %s Locale ComposeFile CacheDir
 [InternalName]\n, argv[0]);
 @@ -53,20 +97,20 @@ int main (int argc, char *argv[]) {
 return 1;
  }

 -src  = malloc (strlen (argv[2]) + 14);
 -len  = strlen (argv[3]) + 15;
 -if (argc == 5)
 -   len += strlen (argv[4]) + 1;
 -dest = malloc (len);
 -if (! src || ! dest) {
 -   perror (* malloc);
 +if (asprintf (src, XCOMPOSEFILE=%s, argv[2]) == -1) {
 +   perror (* asprintf);
 return 1;
  }
 -sprintf (src,  XCOMPOSEFILE=%s, argv[2]);
 +
  if (argc == 4)
 -sprintf (dest, XCOMPOSECACHE=%s, argv[3]);
 +   ret = asprintf (dest, XCOMPOSECACHE=%s, argv[3]);
  else
 -sprintf (dest, XCOMPOSECACHE=%s=%s, argv[3], argv[4]);
 +   ret = asprintf (dest, XCOMPOSECACHE=%s=%s, argv[3], argv[4]);
 +if (ret == -1) {
 +   perror (* asprintf);
 +   return 1;
 +}
 +
  putenv  (src);
  putenv  (dest);
  #if HAVE_UNSETENV
 --
 1.7.9.2

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH v2 10/14] systemd-logind: Add systemd-logind core

[Jasper St. Pierre]

As said before, with systemd user sessions, this will not happen. Unless
I'm misremembering, Lennart has said that the only thing that should be
inside the PAM session environment proper should be the session leader like
gnome-session. (Disregarding the session worker process like
gdm-session-worker)


On Mon, Feb 10, 2014 at 4:54 PM, Hans de Goede hdego...@redhat.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi,

 On 02/10/2014 10:49 PM, David Herrmann wrote:
  Hi
 
  On Mon, Feb 10, 2014 at 10:48 PM, Hans de Goede hdego...@redhat.com
 wrote:
  Hi,
 
  On 02/10/2014 09:58 PM, Jasper St. Pierre wrote:
  Something I noticed here is that you use GetSessionByPID(). This works
 right now, but with systemd user sessions, the display server will run
 outside of a session. We have to decide what to do in this case.
 
  AFAIK that won't work, the display server must be inside the pam login
 session of the user, otherwise logind will refuse to give access to any of
 the devices belonging to the seat.
 
  To be precise, logind will only give access to a process which is
 inside the user-session which is the active session on a certain head, and
 then only to devices which belong to said head.
 
  To be precise, only processes with the uid of the user or root can call
 TakeControl(), no other restrictions are enforced. So the process does not
 have to be in the session.

 Ah right, so I guess it could be outside the user session, as long
 as it gets started with the uid of the user, however I think that starting
 user processes without them being inside a properly setup pam login session
 is very ugly.

 So it would be greatly preferable and more simple IMHO to just start it
 inside the user-session, and AFAIK Ray Strode is working on doing exactly
 that in gdm.

 If we go this route calling GetSessionByPID() should not be a problem
 at all.

 Regards,

 Hans
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iEYEARECAAYFAlL5SnIACgkQF3VEtJrzE/uPCACfUneP1X6T/nKzBo/ZNqIE5XGV
 AeEAnjVXI5BlrBAV4YCkwmcgCRhzdRFR
 =lEt3
 -END PGP SIGNATURE-




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 01/12] dbus-core: Move to hw/xfree86/common dir

[Jasper St. Pierre]

It would mean that we can finally use malloc(); and other reentrant-unsafe
functions in that codepath, which would be a really good code cleanup.


On Thu, Jan 30, 2014 at 5:14 PM, Peter Hutterer peter.hutte...@who-t.netwrote:

 On Thu, Jan 30, 2014 at 12:46:12PM -0500, James Cloos wrote:
  [Still slowly catching up -JimC]
 
   PH == Peter Hutterer peter.hutte...@who-t.net writes:
 
  PH my long-term plan is to replace xf86-input-* with
 xf86-input-libinput.
  PH that is/will be a wrapper around libinput which provides almost
 drop-in
  PH functionality for the other drivers, including a couple of things
 that
  PH weren't possible before with the current driver model.
 
  Back when the attempts were made to move input into a separate thread,
  it occurred to me that we should move input to separate executables.
 
  Ie, have the server listen(2) on a socket for input events, rather than
  link in drivers.

 I think that's splitting along the wrong line. The base idea of input
 threads was to have event generation and event processing in separate
 threads. The former happens inside the SIGIO handler atm, the latter as
 part
 of the mainloop.

 Event generation includes all the driver handling but also the visible
 cursor sprite update - which is where the whole SIGIO idea came from.
 If you split the drivers out into a separate process, you'd split halfway
 through event generation. Which doesn't really get you that much benefit
 other than more latency (the driver polls the fd, then writes to the pipe,
 the server polls the pipe and then updates the cursor sprite).

 A good idea would be to measure if taking away the SIGIO handling from
 drivers has any noticable effects these days. But tbh I don't know how to
 measure this. The actual change is easy though, replace all
 xf86AddEnabledDevice() with AddEnabledDevice() in the drivers (same for the
 remove calls).

 Cheers,
Peter
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: How do we want to deal with 4k tiled displays?

[Jasper St. Pierre]

Is there a reason we can't somehow merge the two CRTCs together into one
virtual CRTC? Too difficult to modeset?



On Thu, Jan 16, 2014 at 2:11 PM, Aaron Plattner aplatt...@nvidia.comwrote:

 So, monitor manufacturers are starting to make high-resolution displays
 that
 consist of one LCD panel that appears to the PC as two.  The one I've got
 is a
 Dell UP2414Q.  It shows up to the PC as two DisplayPort 1.2 multistream
 devices
 that have the same GUID but different EDIDs.  There's an extension block
 in the
 EDID that's supposed to indicate which side is the left tile and which is
 the
 right, though I haven't tried to decode it yet.

 The problem, obviously, is that applications (including some games) treat
 the
 two tiles as if they were completely separate monitors.  Windows maximize
 to
 only half of the screen.  My question is, how do we want to deal with these
 monitors?

 As far as I see it, we have four options:

  1. Hide the presence of the second tile in the X server.

 Somehow combine the two tiles into a single logical output at the RandR
 protocol level.  The X server would be responsible for setting up the
 right
 configuration to drive the logical output using the correct physical
 resources.

  2. Hide the presence of the second tile in libXrandr.

 This would allow interested applications to query the real state of the
 hardware while also making it easier to do modesets on a per-monitor
 level
 rather than per-output.

 This could be exposed either as a new simple modeset API in
 libXrandr or
 similar, or by modifying the existing interface and having a new
 interface
 to punch through the façade and get at the real configuration, for
 clients
 that care.

  3. Update every application that uses RandR 1.2.

 Applications can detect the presence of these monitors and deal with
 them
 themselves, but this might have poor adoption because programmers are
 a lazy
 bunch in general.

  4. Do nothing and hope the problem goes away.

 Hopefully, the situation with current 4k monitors is temporary and
 we'll
 start seeing single-tile 4k displays soon, fixing the problem
 forever.
 Until we get 8k tiled displays.

 If the real output devices are still exposed through the protocol, it
 might make
 sense to add new properties describing their relative positions to make it
 easier for clients to lay them out in the right order.  This might be
 useful for
 power-walls too.

 The problem with the first two options is that driving these monitors
 consumes
 two crtcs.  If we present them as a single output to applications, they'll
 make
 the assumption that they can just assign a single crtc to that output and
 use
 the remaining crtcs for something else.  I suspect that deleting crtcs or
 otherwise marking them as used as a side effect of setting a mode on a
 different
 crtc is going to explode a lot of existing applications.

 ~~

 Regardless of what we do about the current crop of 4k monitors, one
 feature I
 would like to add is a standardized OutputGroup property.  Multiple
 outputs with
 the same value of OutputGroup should be considered (both by clients and the
 server) as a single logical monitor.  This would affect the Xinerama
 information
 presented by rrxinerama.c, and window managers that use RandR 1.2 directly
 would
 be encouraged to consider output groups in their UI behavior.

 The X server could configure OutputGroups automatically when setting up the
 initial configuration based on the presence of tiled displays, and clients
 could
 reconfigure the groups at runtime to get different behavior if desired.

 Does this sound like a reasonable extension to RandR?

 --
 Aaron
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel