On Thu, Jul 09, 2015 at 01:46:46PM -0400, Christopher Michael wrote:
> Here is an updated patch which changes the wording to match what
> Giulio offered.
>
> Documentation for the prepare_lock_surface event description is
> incorrect. The summary says "Tell the client..." however the full-text
> d
On Thu, 9 Jul 2015 13:46:46 -0400
Christopher Michael wrote:
> Here is an updated patch which changes the wording to match what Giulio
> offered.
>
> Documentation for the prepare_lock_surface event description is
> incorrect. The summary says "Tell the client..." however the full-text
> descri
For Elantech touchpads, we know that the resolution is 31u/mm (800dpi) for
v1-v3 firmware. Set this as a hint until we get either the kernel or systemd
to set this for us.
Signed-off-by: Peter Hutterer
---
Until the kernel/systemd are sorted in all distributions, this is the easy
fix. This API is
On Thu, 09 Jul 2015 09:13:54 -0700
Bill Spitzak wrote:
> I thought about having the ID work only once like you propose, but I
> think this means that a client must be able to create unlimited ID's per
> object, and thus a malicious one can fill up the server's map from ID to
> object.
If that
From the man pages it appears this routine can return NULL on certain
error conditions.
Suggested by Marek Chalupa
Signed-off-by: Bryce Harrington
---
xwayland/selection.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xwayland/selection.c b/xwayland/selection.c
index 451b915..2f60c0
On Thu, Jul 09, 2015 at 01:09:35PM -0700, Bill Spitzak wrote:
> On Wed, Jul 8, 2015 at 8:29 PM, Peter Hutterer
> wrote:
>
> >
> > good point, that does seem to be the best approach here.
> > the resolution claimed was 800 dpi -> 31 u/mm.
> > I'm a bit worried about doing this though, the reporter
On Wed, Jul 8, 2015 at 8:29 PM, Peter Hutterer
wrote:
>
> good point, that does seem to be the best approach here.
> the resolution claimed was 800 dpi -> 31 u/mm.
> I'm a bit worried about doing this though, the reporter in
> https://bugs.freedesktop.org/show_bug.cgi?id=90101
> measured a touchp
On Wed, Jul 8, 2015 at 11:38 PM, Peter Hutterer
wrote:
>
> and since we say that we normalize to [0, 1], the _correct_ value is 1 when
> we have a touch. it makes client code more straightforward because you can
> rely on the value being useful.
> if clients end up needing to know whether there
On Thu, Jul 9, 2015 at 5:58 AM, Jonas Ådahl wrote:
>
> Yea, an inverse of xdg_surface.set_parent on xdg_foreign sounds like the
> best option to me too. We can't be too specific though, adding too much
> DE design into the protocol (like making it modal or other things that
> might not apply to n
Here is an updated patch which changes the wording to match what Giulio
offered.
Documentation for the prepare_lock_surface event description is
incorrect. The summary says "Tell the client..." however the full-text
description says "tell the shell..."
Signed-off-by: Chris Michael
---
protoco
On 07/09/2015 01:33 PM, Giulio Camuffo wrote:
2015-07-09 20:12 GMT+03:00 Jasper St. Pierre :
The shell is a client. Both are technically correct, but I'm fine with
this change if it makes things easier to read. We do use the terms
"shell" and "client" way too much. :)
Imho this makes it a bit
2015-07-09 20:12 GMT+03:00 Jasper St. Pierre :
> The shell is a client. Both are technically correct, but I'm fine with
> this change if it makes things easier to read. We do use the terms
> "shell" and "client" way too much. :)
Imho this makes it a bit harder to read, as shell can mean either the
The shell is a client. Both are technically correct, but I'm fine with
this change if it makes things easier to read. We do use the terms
"shell" and "client" way too much. :)
On Thu, Jul 9, 2015 at 10:07 AM, Christopher Michael
wrote:
> Documentation for the prepare_lock_surface event descriptio
Documentation for the prepare_lock_surface event description
is incorrect as it says to "tell the client to create..." however it is
actually the shell which creates the lock surface.
Signed-off-by: Chris Michael
---
protocol/desktop-shell.xml | 2 +-
1 file changed, 1 insertion(+), 1 deleti
On 07/09/2015 02:19 AM, Jasper St. Pierre wrote:
Calling sandboxed_surface_manager.get_surface_for_id(); retrieves that
surface and deletes the ID from the global namespace.
I thought about having the ID work only once like you propose, but I
think this means that a client must be able to cre
No, it's not the same thing. You want an xdg_surface interface exposed
on both sides. We don't want that. The resulting derail was us
collectively ramming our heads straight into the wall trying to figure
out any way that having the same interface exposed on both sides could
make any sense.
xdg_su
On 07/09/2015 02:21 AM, Jonas Ådahl wrote:
That is more or less what was the idea before the thread derailed.
I have no idea why you think my proposal "derailed" this when I was
attempting to describe EXACTLY the same thing you are, except I replaced
"fd" with a "key" which I figured is a 12
On Thu, Jul 09, 2015 at 03:10:51PM +0200, Alexander Larsson wrote:
> On Thu, 2015-07-09 at 20:58 +0800, Jonas Ådahl wrote:
> > On Thu, Jul 09, 2015 at 01:26:09PM +0100, Daniel Stone wrote:
>
> > > Or rather, xdg_foreign.reparent_as_dialog_into(xdg_surface). I like
> > > the idea of limiting the su
On Sat, 27 Jun 2015 14:07:41 +0300
Giulio Camuffo wrote:
> This is a preliminary change for libweston, with no functional modifications.
> Separate the backends and the core weston_compositor struct, by creating
> the weston_compositor in the main(), and having the various backends extend
> the w
On Thu, 2015-07-09 at 20:58 +0800, Jonas Ådahl wrote:
> On Thu, Jul 09, 2015 at 01:26:09PM +0100, Daniel Stone wrote:
> > Or rather, xdg_foreign.reparent_as_dialog_into(xdg_surface). I like
> > the idea of limiting the surface area as much as possible, to not
> > only
> > make it explicit as to w
On Thu, Jul 09, 2015 at 01:26:09PM +0100, Daniel Stone wrote:
> Hi,
>
> On 9 July 2015 at 12:51, Alexander Larsson wrote:
> > So, you disagree with xdg_surface.set_parent accepting both xdg_surface
> > and xdg_foreign objects?
>
> It can't. Typing is very strict, and there is no subtyping.
> xdg
Hi,
On 9 July 2015 at 12:51, Alexander Larsson wrote:
> So, you disagree with xdg_surface.set_parent accepting both xdg_surface
> and xdg_foreign objects?
It can't. Typing is very strict, and there is no subtyping.
xdg_surface doesn't extend wl_surface in a traditional (C++/Java)
style inherited
On Thu, 2015-07-09 at 13:38 +0300, Pekka Paalanen wrote:
> On Thu, 09 Jul 2015 11:37:06 +0200
> Alexander Larsson wrote:
>
> > On Thu, 2015-07-09 at 02:19 -0700, Jasper St. Pierre wrote:
> > > My issue with this is that you're tying two things together. You
> > > want
> > > access to """a surfac
On Thu, Jul 09, 2015 at 01:38:32PM +0300, Pekka Paalanen wrote:
> On Thu, 09 Jul 2015 11:37:06 +0200
> Alexander Larsson wrote:
>
> > On Thu, 2015-07-09 at 02:19 -0700, Jasper St. Pierre wrote:
> > > My issue with this is that you're tying two things together. You want
> > > access to """a surfac
On Thu, 09 Jul 2015 11:37:06 +0200
Alexander Larsson wrote:
> On Thu, 2015-07-09 at 02:19 -0700, Jasper St. Pierre wrote:
> > My issue with this is that you're tying two things together. You want
> > access to """a surface""", and you think you can do this by having
> > global cross-client object
On Thu, 2015-07-09 at 02:19 -0700, Jasper St. Pierre wrote:
> My issue with this is that you're tying two things together. You want
> access to """a surface""", and you think you can do this by having
> global cross-client objects and handles and such. I don't see a need
> for this. We can just add
On Thu, 2015-07-09 at 10:00 +0100, Daniel Stone wrote:
> > However, the problem I have now is different, in that it involves
> > an
> > existing, less privileged client initiating a higher privileged
> > operation (in a controlled fashion) and the higher privileged
> > client
> > needing to refe
On Thu, Jul 09, 2015 at 10:00:56AM +0100, Daniel Stone wrote:
> Hi Alex,
>
> On 9 July 2015 at 09:44, Alexander Larsson wrote:
> > On Wed, 2015-07-08 at 12:47 +0100, Daniel Stone wrote:
> >> This thread has sadly degenerated into: 'what if Wayland's object
> >> model was totally different? what i
My issue with this is that you're tying two things together. You want
access to """a surface""", and you think you can do this by having
global cross-client objects and handles and such. I don't see a need
for this. We can just add a new protocol that does what we want.
We have a few requirements:
Hi Alex,
On 9 July 2015 at 09:44, Alexander Larsson wrote:
> On Wed, 2015-07-08 at 12:47 +0100, Daniel Stone wrote:
>> This thread has sadly degenerated into: 'what if Wayland's object
>> model was totally different? what if some of its explicit core design
>> principles were thrown out the windo
On Wed, 2015-07-08 at 12:47 +0100, Daniel Stone wrote:
> Hi,
> None of them will really work.
>
> This thread has sadly degenerated into: 'what if Wayland's object
> model was totally different? what if some of its explicit core design
> principles were thrown out the window?'. Realistically, tha
Hi,
On 8 July 2015 at 18:46, Bill Spitzak wrote:
> All your objections sounds like you are confusing the implementation with
> the abstraction that the client program sees. A few examples:
No, not at all. On the contrary ...
> On Wed, Jul 8, 2015 at 4:47 AM, Daniel Stone wrote:
>
>> > Yes this
Hi,
On 09-07-15 07:31, Peter Hutterer wrote:
Some model-specific information isn't available through udev properties. This
callout is used to query the device directly and set a property that we can
then match on for the hwdb entries.
This is geared for Elantech and ALPS touchpads where the fir
33 matches
Mail list logo
