Re: [PATCH kdrive/ephyr v7 3/9] kdrive: introduce input hot-plugging support for udev and hal backends (#33140)

2016-02-11 Thread Laércio de Sousa 
2016-02-11 0:56 GMT-02:00 Peter Hutterer :

> we don't have a 1:1 mapping between devices and fd (e.g. wacom devices all
> hang off a single fd). Even the fd itself is a DDX concept, so RemoveDevice
> cannot close the fd.
>
> What should happen here though is that the pDev->public.devicePrivate
> points
> to something kdrive understands and that includes the fd.
>
Reading kdrive evdev sources, I've found that
EvdevPtrDisable/EvdevKbdDisable functions
do have a KdUnregisterFd() call. Example:

static void
EvdevPtrDisable(KdPointerInfo * pi)
{
Kevdev *ke;

ke = pi->driverPrivate;

if (!pi || !pi->driverPrivate)
return;

KdUnregisterFd(pi, ke->fd, TRUE);

if (ioctl(ke->fd, EVIOCGRAB, 0) < 0)
perror("Ungrabbing evdev mouse device failed");

free(ke);
pi->driverPrivate = 0;
}

However, it seems to fail in my system, because I always get
that "Ungrabbing evdev mouse device failed" error message.

-- 
*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: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH kdrive/ephyr v7 3/9] kdrive: introduce input hot-plugging support for udev and hal backends (#33140)

2016-02-11 Thread Peter Hutterer 
On Thu, Feb 11, 2016 at 08:23:55AM -0200, Laércio de Sousa wrote:
> 2016-02-11 0:56 GMT-02:00 Peter Hutterer :
> 
> > we don't have a 1:1 mapping between devices and fd (e.g. wacom devices all
> > hang off a single fd). Even the fd itself is a DDX concept, so RemoveDevice
> > cannot close the fd.
> >
> > What should happen here though is that the pDev->public.devicePrivate
> > points
> > to something kdrive understands and that includes the fd.
> >
> Reading kdrive evdev sources, I've found that
> EvdevPtrDisable/EvdevKbdDisable functions
> do have a KdUnregisterFd() call. Example:
> 
> static void
> EvdevPtrDisable(KdPointerInfo * pi)
> {
> Kevdev *ke;
> 
> ke = pi->driverPrivate;
> 
> if (!pi || !pi->driverPrivate)
> return;
> 
> KdUnregisterFd(pi, ke->fd, TRUE);
> 
> if (ioctl(ke->fd, EVIOCGRAB, 0) < 0)
> perror("Ungrabbing evdev mouse device failed");
> 
> free(ke);
> pi->driverPrivate = 0;
> }
> 
> However, it seems to fail in my system, because I always get
> that "Ungrabbing evdev mouse device failed" error message.

I just checked the kernel sources and there is no specific error case that
this code can trigger, it's something to do with the fd itself (EBADF,
EPERM, etc.). I guess fd is already closed/reset by the time you get here.
What errno do you get?

Cheers,
   Peter
___
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 kdrive/ephyr v7 3/9] kdrive: introduce input hot-plugging support for udev and hal backends (#33140)

2016-02-11 Thread Peter Hutterer 
On Thu, Feb 11, 2016 at 04:10:23PM -0200, Laércio de Sousa wrote:
> 2016-02-11 8:23 GMT-02:00 Laércio de Sousa <
> laercioso...@sme-mogidascruzes.sp.gov.br>:
> 
> > 2016-02-11 0:56 GMT-02:00 Peter Hutterer :
> >
> >> we don't have a 1:1 mapping between devices and fd (e.g. wacom devices all
> >> hang off a single fd). Even the fd itself is a DDX concept, so
> >> RemoveDevice
> >> cannot close the fd.
> >>
> >> What should happen here though is that the pDev->public.devicePrivate
> >> points
> >> to something kdrive understands and that includes the fd.
> >>
> > Reading kdrive evdev sources, I've found that
> > EvdevPtrDisable/EvdevKbdDisable functions
> > do have a KdUnregisterFd() call. Example:
> >
> > static void
> > EvdevPtrDisable(KdPointerInfo * pi)
> > {
> > Kevdev *ke;
> >
> > ke = pi->driverPrivate;
> >
> > if (!pi || !pi->driverPrivate)
> > return;
> >
> > KdUnregisterFd(pi, ke->fd, TRUE);
> >
> > if (ioctl(ke->fd, EVIOCGRAB, 0) < 0)
> > perror("Ungrabbing evdev mouse device failed");
> >
> > free(ke);
> > pi->driverPrivate = 0;
> > }
> >
> > However, it seems to fail in my system, because I always get
> > that "Ungrabbing evdev mouse device failed" error message.
> >
> I'm convincing myself this is more a ploblem with kdrive evdev driver than
> with kdrive itself, so I'm tempted to keep that code in
> DeleteInputDeviceRequest() as is, with a mention that it's a kind of
> "safety measure against buggy drivers". What do you think?

tbh, I think it's easier if we just fix buggy drivers. it's not like we have
that many of them :)

Cheers,
   Peter
___
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 v3 0/9] PRIME Synchronization

2016-02-11 Thread Alex Goins 
Pinging in case this got buried.

Thanks,
Alex

> Hello all,
> 
> These patches change the xserver to support setting up PRIME with double
> buffering, and implement double buffered PRIME sink support in the
> modesetting driver. In addition to these changes, I've upstreamed a couple
> of patches to the i915 DRM driver that mesh with these, and have
> implemented double buffered PRIME source support in the NVIDIA proprietary
> driver (pending release.)
> 
> Previous cover letters:
> v2: http://lists.x.org/archives/xorg-devel/2016-January/048434.html
> v1: http://lists.x.org/archives/xorg-devel/2015-November/048039.html
> 
> In this patch set there are a few changes:
> 1) Moved some of the ABI functions into rrScrPrivRec instead of
>ScreenRec.
>
>In the case of (rr)StartFlippingPixmapTracking(), it was
>because I needed to add the RRCrtc as a parameter so that the source
>driver can be aware of the outputs being used.
> 
>In the case of (rr)(Enable/Disable)SharedPixmapFlipping(), I was
>previously passing in the xf86CrtcPtr as a void*, which is kind of
>gross. It makes more sense to pass in the RRCrtcPtr and get the
>xf86CrtcPtr from there, necessitating an rrScrPrivRec ABI function.
> 
>It may be best to move all of the ABI functions to rrScrPrivRec
>regardless of whether or not they need to use RandR-specific data
>types, since none of them make sense without RandR enabled. However,
>since the old pixmap sharing functions are in ScreenRec, I left
>functions there where possible. If you would prefer them in
>rrScrPrivRec, just let me know.
> 
> 2) Made damage get flushed to the kernel driver for both scanout
>pixmaps, rather than just the latest one to get damage registered.
> 
> 3) Added comments to the output property code indicating that it will
>need to be reworked if an when we support different source providers
>for different outputs.
> 
> 4) Made RandR check the current value of the output property if there
>is no pending value. Previously, it failed to correctly pick up on
>the default value, although it didn't cause a visible bug since with
>no value it defaults to TRUE.
> 
> 5) Made RandR set the output property to 0 if it has to fall back to
>unsynchronized PRIME, so that if the user checks the value it will
>reflect the current state of the system.
> 
> 6) Made RandR fall back on unsynchronized pixmap sharing if the PRIME
>flipping functions fail.
> 
> 7) Blacklisted UDL for PRIME synchronization in the modesetting driver,
>making it fail rrEnableSharedPixmapFlapping() so that RandR falls
>back on unsynchronized PRIME. UDL has several issues that prevent it
>from working properly with PRIME synchronization.
> 
>See commit message for "modesetting: Blacklist UDL from PRIME sync"
>for details.
> 
> Thanks, Alex @ NVIDIA Linux Driver Team
> 
> Alex Goins (9):
>   xf86: Add PRIME flipping functions to Screen
>   randr/xf86: Add PRIME Synchronization / Double Buffer
>   randr: Add ability to turn PRIME sync off
>   randr: Cleanup rrSetupPixmapSharing()
>   modesetting: Properly clean up w/ PRIME syncing
>   modesetting: Implement PRIME syncing as a sink
>   modesetting: Fix mmap leak in scanout_pixmap_cpu
>   modesetting: Suspend and resume flipping with DPMS
>   modesetting: Blacklist UDL from PRIME sync
> 
>  hw/xfree86/drivers/modesetting/driver.c  |  96 ++--
>  hw/xfree86/drivers/modesetting/drmmode_display.c | 282 
> +--
>  hw/xfree86/drivers/modesetting/drmmode_display.h |  17 +-
>  hw/xfree86/modes/xf86Crtc.h  |   4 +
>  hw/xfree86/modes/xf86RandR12.c   |   4 +-
>  include/scrnintstr.h |  14 ++
>  randr/randrstr.h |  17 ++
>  randr/rrcrtc.c   | 158 +++--
>  randr/rrprovider.c   |  57 +
>  9 files changed, 599 insertions(+), 50 deletions(-)
> 
> -- 
> 1.9.1
> 
> 
___
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 kdrive/ephyr v7 3/9] kdrive: introduce input hot-plugging support for udev and hal backends (#33140)

2016-02-11 Thread Laércio de Sousa 
2016-02-11 8:23 GMT-02:00 Laércio de Sousa <
laercioso...@sme-mogidascruzes.sp.gov.br>:

> 2016-02-11 0:56 GMT-02:00 Peter Hutterer :
>
>> we don't have a 1:1 mapping between devices and fd (e.g. wacom devices all
>> hang off a single fd). Even the fd itself is a DDX concept, so
>> RemoveDevice
>> cannot close the fd.
>>
>> What should happen here though is that the pDev->public.devicePrivate
>> points
>> to something kdrive understands and that includes the fd.
>>
> Reading kdrive evdev sources, I've found that
> EvdevPtrDisable/EvdevKbdDisable functions
> do have a KdUnregisterFd() call. Example:
>
> static void
> EvdevPtrDisable(KdPointerInfo * pi)
> {
> Kevdev *ke;
>
> ke = pi->driverPrivate;
>
> if (!pi || !pi->driverPrivate)
> return;
>
> KdUnregisterFd(pi, ke->fd, TRUE);
>
> if (ioctl(ke->fd, EVIOCGRAB, 0) < 0)
> perror("Ungrabbing evdev mouse device failed");
>
> free(ke);
> pi->driverPrivate = 0;
> }
>
> However, it seems to fail in my system, because I always get
> that "Ungrabbing evdev mouse device failed" error message.
>
I'm convincing myself this is more a ploblem with kdrive evdev driver than
with kdrive itself, so I'm tempted to keep that code in
DeleteInputDeviceRequest() as is, with a mention that it's a kind of
"safety measure against buggy drivers". What do you think?


-- 
*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: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] dri2: Use the work queue to manage client sleeps

2016-02-11 Thread Chris Wilson 
On Wed, Feb 10, 2016 at 11:51:18AM -0500, Adam Jackson wrote:
> @@ -983,7 +990,7 @@ DRI2WakeClient(ClientPtr client, DrawablePtr pDraw, int 
> frame,
>  {
>  ScreenPtr pScreen = pDraw->pScreen;
>  DRI2DrawablePtr pPriv;
> -
> +t

Without this,
Tested-by: Chris Wilson 
Reviewed-by: Chris Wilson 
-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: https://lists.x.org/mailman/listinfo/xorg-devel