Re: [PATCH 5/5] modesetting: Implement page flipping support for Present.

2015-04-27 Thread Kenneth Graunke 
On Tuesday, April 21, 2015 05:58:44 PM Kenneth Graunke wrote:
> Based on code by Keith Packard, Eric Anholt, and Jason Ekstrand.
> 
> v2:
> - Fix double free and flip_count underrun (caught by Mario Kleiner).
> - Don't leak flip_vblank_event on the error_out path (Mario).
> - Use the updated ms_flush_drm_events API (Mario, Ken).
> 
> v3: Hack around DPMS shenanigans.  If all monitors are DPMS off, then
> there is no active framebuffer; attempting to pageflip will hit the
> error_undo paths, causing us to drmModeRmFB with no framebuffer,
> which confuses the kernel into doing full modesets and generally
> breaks things.  To avoid this, make ms_present_check_flip check that
> some CRTCs are enabled and DPMS on.  This is an ugly hack that would
> get better with atomic modesetting, or some core Present work.
> 
> v4:
> - Don't do pageflipping if CRTCs are rotated (caught by Jason Ekstrand).
> - Make pageflipping optional (Option "PageFlip" in xorg.conf.d), but
>   enabled by default.
> 
> Signed-off-by: Kenneth Graunke 

Upon further testing, there are still nasty DPMS bugs affecting this
patch.  We no longer crash the X server, but clients appear to
occasionally get stuck.

I guess we just need to bite the bullet and unflip on DPMS off.
Or switch to atomic modesetting...


signature.asc
Description: This is a digitally signed message part.
___
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] Include config.h before anything else in *.c

2015-04-27 Thread Alan Coopersmith 

On 04/26/15 06:24 AM, Julien Cristau wrote:

Drop _GNU_SOURCE defines that are redundant with AC_USE_SYSTEM_EXTENSIONS.

Debian bug#749008 

Reported-by: Michael Tautschnig 
Signed-off-by: Julien Cristau 
---
  src/common_capability.c  | 3 +++
  src/common_init.c| 3 +++
  src/common_interface.c   | 3 +++
  src/common_io.c  | 3 +++
  src/common_iterator.c| 3 +++
  src/common_map.c | 3 +++
  src/common_vgaarb_stub.c | 3 +++
  src/linux_devmem.c   | 5 +++--
  src/openbsd_pci.c| 3 +++
  src/solx_devfs.c | 3 +++
  src/x86_pci.c| 4 +++-
  11 files changed, 33 insertions(+), 3 deletions(-)


Reviewed-by: Alan Coopersmith 

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
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: [X11] Question about TouchCancel event like ACTION_CANCEL in android

2015-04-27 Thread Peter Hutterer 
sorry about the delay.

On Thu, Apr 16, 2015 at 08:19:57PM +0900, 강정현 wrote:
> > From: Peter Hutterer [mailto:peter.hutte...@who-t.net]
> > Sent: Thursday, April 16, 2015 4:38 PM
> > Cc: xorg-devel@lists.x.org
> > Subject: Re: [X11] Question about TouchCancel event like ACTION_CANCEL in
> > android
> > 
> > On Thu, Apr 16, 2015 at 03:50:41PM +0900,wrote:
> > > Hello, Peter Hutterer.
> > >
> > > I  m planning to add a   Event cancel  (Touch Cancel?) event in x11
> > > protocol.
> > >
> > > Like below article I want to send a event to apps for notification
> > > about current events are canceled!.
> > >
> > >
> > >
> > > How/What I doing for this job?
> > >
> > > I need your advise. Please give me your help.
> > 
> > what's the use-case you're trying to solve? many use-cases for cancel can
> > be solved with the touch ownership approach, the remaining ones may be a
> > valid justification but you'll be running into the issue that no
> > application currently supports cancel so if you do add this you can only
> > add it to the TouchEnd. and most applications will think it's a normal
> > touch release and proceed as normal.
> > 
> > Cheers,
> >Peter
> 
> Thank you for your reply.
> 
> I understand your worry. Yes. Currently there are no applications exist 
> to support the cancel event. Only my own applications will work if I add 
> a touch cancel event. But I know this issue, so I want to make 
> a cancel event at least only my own applications are work.
> 
> And I have some concern to touch ownership event will work normally about
> single finger touches. Single finger events are generated to emulated
> pointer events such as ButtonPress/Motion/ButtonRelease instead of
> TouchBegin/TouchUpdate/TouchEnd events.
> 
> One of use-case is releated this.
> 
> For example, assume that two full screen window are exist, WinA and WinB.
> The WinA is top-visible window, so it can get touch events. And WinA launch
> AppC if it get tap event(ButtonPress/Motion/ButtonRelease).
> The WinB is going to be top-visible window, if the HomeKey is pressed.
> In this situation, when I press WinA and WinA get a ButtonPress event. And I
> press HomeKey while touch press, WinA is disappeared and WinB is appeared.
> Window stack is changed. But Button events are keep going to propagate to 
> WinA although WinA disappeared on screen. And then if I release my touch,
> WinA get a ButtonRelease event and AppC will be launched.
> 
> How can I resolve this use-case?

yeah, fair enough. iirc the current implementation handles it when windows
change but only when windows drop out of the list, not when they get added
or re-stacked. so this is a valid case for cancel events, but the next
problem will be how to notice that. In a composited desktop, I don't think
the server has enough information for when to cancel touch sequences, right?

Cheers,
   Peter

> > > From:[mailto:jhyuni.k...@samsung.com]
> > > Sent: Wednesday, April 15, 2015 7:39 PM
> > > To: 'xorg-devel@lists.x.org'
> > > Subject: [X11] Question about TouchCancel event like ACTION_CANCEL in
> > > android
> > >
> > >
> > >
> > > Hello, Dears.
> > >
> > > I send this email again. Because of HTML (not text)
> > >
> > >
> > >
> > > I'm planning to add a touch cancel event(like ACTION_CANCEL in
> > > Android) in
> > > X11 protocol.
> > >
> > >
> > >
> > > So I invested XI events and I found a variable named "flags" in
> > > DeviceEvent structure.
> > >
> > > The "flags" variable can get values like below.
> > >
> > >
> > >
> > > ==
> > >
> > > (defined in XI2.h)
> > >
> > > /* Device event flags (common) */
> > >
> > > /* Device event flags (key events only) */
> > >
> > > #define XIKeyRepeat (1 << 16)
> > >
> > > /* Device event flags (pointer events only) */
> > >
> > > #define XIPointerEmulated   (1 << 16)
> > >
> > > /* Device event flags (touch events only) */
> > >
> > > #define XITouchPendingEnd   (1 << 16)
> > >
> > > #define XITouchEmulatingPointer (1 << 17)
> > >
> > > ==
> > >
> > >
> > >
> > > So I think how about insert "Device event flags" for a touch cancel
> > > event like below.
> > >
> > > #define XITouchCancel  (1 << 18)
> > >
> > > or
> > >
> > > #define XIPointerCancel (1 << 18)
> > >
> > > we can distinguish Normal touch events and a touch cancel event using
> > > XITouchCancel definition.
> > >
> > >
> > >
> > > Another way is make new events: struct TouchCancelEvent( have a type
> > > "XI_TouchCancel")
> > >
> > >
> > >
> > > Each method has its advantages and disadvantages.
> > >
> > >
> > >
> > > So I hope to hear opinions.
> > >
> > > Would you give me some advice or opinion?
> > >
> > >
> > >
> > > I will wait your reply.
> > >
> > > Best regards,
> > >
> > > Jeonghyun Kang.
> > >
> > >
> > >
> 
___
xorg-