On Mon, May 14, 2018 at 07:51:33AM +0200, Markus Ongyerth wrote:
> On 2018/5月/11 10:12, Peter Hutterer wrote:
> >
> > > Never the less, a few pointers to the varlink approach from my side:
> > > From your quick outline in the mail, I asume you plan to have the varlink
> > > fd
> > > libinput own
On 2018/5月/11 10:12, Peter Hutterer wrote:
>
> > Never the less, a few pointers to the varlink approach from my side:
> > From your quick outline in the mail, I asume you plan to have the varlink
> > fd
> > libinput owned? I don't think that fits the current scope of libinput (or
> > that
> >
restoring the CC list, because thunderbird...
On Sun, May 13, 2018 at 10:19:34AM -0400, Drew DeVault wrote:
> On 2018-05-13 5:35 PM, Peter Hutterer wrote:
> > On 11/5/18 21:38 , Drew DeVault wrote:
> > > Maybe `ltrace --library=libinput.so ./run-compositor` would be
> > > sufficient?
> >
> > May
On Sun, May 13, 2018 at 05:31:30PM +1000, Peter Hutterer wrote:
> On 13/5/18 01:04 , Pekka Paalanen wrote:
> > On Thu, 10 May 2018 10:10:10 +0200
> > Markus Ongyerth wrote:
> >
> > > For the reasons stated above, I think we would be better suited with an
> > > interface defined as wayland extensi
On 13/5/18 01:04 , Pekka Paalanen wrote:
On Thu, 10 May 2018 10:10:10 +0200
Markus Ongyerth wrote:
For the reasons stated above, I think we would be better suited with an
interface defined as wayland extension. The downside is, that it has to be
proxied and implemented by the compositor, but I
On Thu, 10 May 2018 10:10:10 +0200
Markus Ongyerth wrote:
> For the reasons stated above, I think we would be better suited with an
> interface defined as wayland extension. The downside is, that it has to be
> proxied and implemented by the compositor, but I think the advantages
> outweigh
>
On Thu, May 10, 2018 at 03:07:36PM +1000, Peter Hutterer wrote:
> one of the issues we have with libinput in the wayland world is that
> debugging it is a bit harder than in X. There we can just run xinput
> list-props and get an idea of what settings are applied to each device which
> helps narrow
Maybe `ltrace --library=libinput.so ./run-compositor` would be
sufficient?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Thu, May 10, 2018 at 08:34:56PM -0400, Drew DeVault wrote:
> Does it make more sense to make libinput provide this information in a
> structured/predictable way via its log callback, then pull that out of
> compositor logs?
I've just done something like this to debug pointer acceleration in the
Does it make more sense to make libinput provide this information in a
structured/predictable way via its log callback, then pull that out of
compositor logs?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org
So we don't cross the streams, some motivation is in the reply to Drew,
https://lists.freedesktop.org/archives/wayland-devel/2018-May/038148.html
I'll try to avoid duplication of those points here.
On Thu, May 10, 2018 at 10:10:10AM +0200, Markus Ongyerth wrote:
> A quick glance at varlink makes m
On Thu, May 10, 2018 at 08:23:31AM -0400, Drew DeVault wrote:
> Can you be more specific about your use-case? As far as I can tell, you
> want to find out how the devices were configured by the compositor. On
> sway this is as straightforward as reading sway's debug log.
>
> I guess I'm not clear
Can you be more specific about your use-case? As far as I can tell, you
want to find out how the devices were configured by the compositor. On
sway this is as straightforward as reading sway's debug log.
I guess I'm not clear on why a more complex solution is necessary.
--
Drew DeVault
__
A quick glance at varlink makes me like it more than dbus, but I'm not sure
it's the best choice to provide debug information about libinput configuration
in compositors.
All compositors I'm aware of, provide an IPC method for some (more or less)
internals. GNOME (and afaik KDE) have dbus, sway
one of the issues we have with libinput in the wayland world is that
debugging it is a bit harder than in X. There we can just run xinput
list-props and get an idea of what settings are applied to each device which
helps narrow down where the issue really is. Under Wayland, that is not
available, f
15 matches
Mail list logo
