Hi,
On 3 December 2015 at 17:23, Chris Michael wrote:
> Patch updated to remove dead lines as suggested by Daniel Stone
>
> Signed-off-by: Chris Michael
Sorry, should've said, that with that:
Reviewed-by: Daniel Stone
Cheers,
Daniel
_
inter correctly.
It's an entirely valid concern, and I don't want people to do it, but
documenting historical mistakes is useful as a signpost to people of
what not to do. And it's now much less wishy-washy, and much more
'this was a bad idea; do not do
ancel
Thanks for the fixups. For the series:
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Hi,
On 9 December 2015 at 16:29, Giulio Camuffo wrote:
> +enum weston_drm_backend_output_mode {
> + /** The output is disabled */
> + WESTON_DRM_BACKEND_OUTPUT_OFF,
> + /** The output will use the current active mode */
> + WESTON_DRM_BACKEND_OUTPUT_CURRENT,
> + /**
Hi,
On 14 December 2015 at 11:40, Pekka Paalanen wrote:
> On Tue, 08 Dec 2015 14:48:01 +0100
> Matthias Treydte wrote:
>> Either way, using the scaler API causes either too much drawing when
>> used without setting the damage region (variant (b) above then should
>> change nothing on screen at a
On 14 December 2015 at 12:49, Daniel Stone wrote:
> On 14 December 2015 at 11:40, Pekka Paalanen wrote:
>> On Tue, 08 Dec 2015 14:48:01 +0100
>> Matthias Treydte wrote:
>>> Either way, using the scaler API causes either too much drawing when
>>> used without s
Hi,
On 7 January 2014 19:22, Maarten Baert wrote:
> @Martin Peres: Your ideas are nice in theory, but as Sebastian Wick already
> said, it is just not practical.
>
> If you want a specific example, I have one:
> https://github.com/MaartenBaert/ssr
> The sole purpose of this application is to reco
Hi,
The macro should really be called WESTON_VERSION_COMPATIBLE_WITH() -
it's done that way specifically to allow breaking API/ABI at least
every minor release.
Cheers,
Daniel
On 24 January 2014 19:11, U. Artie Eoff wrote:
> From: "U. Artie Eoff"
>
> Fixes: https://bugs.freedesktop.org/show_bug
Hi,
On 10 February 2014 13:23, Emilio Pozuelo Monfort wrote:
> When a view was destroyed while we were on exposay, we didn't
> remove it from the list of views, and so when leaving exposay
> we were trying to animate (and sometimes activate) a
> non-existent view, causing a crash.
This should tr
Hi,
On 18 February 2014 22:47, Peter Hutterer wrote:
> Avoids erroneous timestamps when the system time is reset. This used to a be a
> problem with the X.Org synaptics driver where taps, scrolling and a couple of
> other things would potentially lock up.
Can this be CLOCK_MONOTONIC_COARSE inste
Hi,
On 7 March 2014 13:03, Pekka Paalanen wrote:
> Merge more code into a common function. No functional changes.
Quick nitpick: does this not break all the pixman_region32_*() calls
in weston_surface_commit(), which rely on surface->{width,height}?
Should be pretty easy to see this breakage whe
Hi,
On 11 March 2014 14:30, Pekka Paalanen wrote:
> On X11 you are probably used to getting an opaque window, no matter
> what values you write to the alpha channel. On Wayland, the alpha
> channel is actually used by the server to blend your window to the rest
> of the desktop, always.
... alwa
Hi,
On 19 March 2014 13:18, Jasper St. Pierre wrote:
> For very simple use cases, it's fairly mature. You can use it on embedded
> systems quite well.
>
> For complex desktops, it's not quite. There's a lot of protocols that are
> traditionally in something like the ICCCM or EWMH that we have to
Hi,
On 27 March 2014 22:41, Ran Benita wrote:
> On Thu, Mar 27, 2014 at 09:04:07PM +0100, David Herrmann wrote:
> > On Thu, Mar 27, 2014 at 8:22 PM, Ran Benita wrote:
> > > - Added two new functions, xkb_state_key_get_utf{8,32}(). They
> > > combine the operations of xkb_state_key_get_syms()
Hi,
On 9 April 2014 20:02, Jonas Ådahl wrote:
> Don't have a hard coded (previously 16) slot array size; instead
> allocate dynamically depending what slots are assigned. There is still a
> hard coded max though, to protect from invalid input, but its changed
> to 60.
>
Won't this break xf86-in
Hi,
On 11 April 2014 21:49, Bill Spitzak wrote:
>
> On 04/11/2014 01:10 PM, Hardening wrote:
>>
>> I have heard that in some cases windows layouts (which are also RDP ones)
>> don't match exact the XKB ones :(. So the surprises can come when using
>> mstsc against a linux host.
>>
>> I have had
Hi,
On 15 April 2014 13:28, Hans de Goede wrote:
> Apple touchpads don't have visible markings for the software button areas
> that almost all other vendors use. OS X provides clickfinger behaviour
> instead, where a click with two fingers on the touchpad generate a right
> button click. Use tha
On 7 May 2014 20:23, Bill Spitzak wrote:
> If a subsurface belongs to a different client than the parent surface,
> though, does this mean the child client will get events that have an xy
> position relative to the parent surface?
As a fundamental design point of the Wayland protocol is that cl
Hi,
On 9 May 2014 08:34, Pekka Paalanen wrote:
> On Thu, 08 May 2014 10:52:51 -0700
> Bill Spitzak wrote:
> > Possibly you are reading the words "save/restore" literally, in that you
> > are imagining some blob of data stored in the compositor that is
> > recognized to restore the layout. Howev
On 29 May 2014 18:54, Jason Gerecke wrote:
> If that's the case though, I have to ask -- *why* on Earth is
> 'li_fixed_t' even being considered as libinput's output type? I know
> I'm missing something because the thought seems like such a blindingly
> terrible choice. Its not an intrinsic type,
Hi,
On 1 June 2014 02:03, José Expósito wrote:
> And I say more or less because it is necessary to put 3 fingers on the
> trackpad to start moving the rectangles...
> Anyway, the program is not working on Weston. My question is, is that
> because Weston doesn't implement multitouch support or b
On 2 June 2014 08:44, Kishore Divvela -ERS, HCL Tech
wrote:
>Can I use the build steps which is available in
> http://wayland.freedesktop.org/building.html.
>
Yes.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.free
Hi,
On 5 June 2014 07:49, Pekka Paalanen wrote:
> Then thinking about how that would work over a protocol like Wayland; A
> client is creating a buffer, and wants the compositor to present it,
> putting it on a hardware overlay if possible, or even scanning it
> out directly. We would like to k
Hi,
On 9 June 2014 12:06, Pekka Paalanen wrote:
> On Mon, 9 Jun 2014 11:00:04 +0200
> Benjamin Gaignard wrote:
> > One of the main comment on the latest patches was that wl_dmabuf use
> > DRM for buffer allocation.
> > This appear to be an issue since wayland doesn't want to rely on one
> > spe
On 1 July 2014 21:05, Bill Spitzak wrote:
>
> On 07/01/2014 12:57 PM, Jasper St. Pierre wrote:
>
>> It sounds like you have a highly technical workstation platform that has
>>
> a complex, professional tool involving multiple windows, and you are
>> fully aware of your environment. You can keep us
Hi,
On 14 July 2014 14:52, Giulio Camuffo wrote:
> @@ -851,6 +851,7 @@ wl_display_roundtrip(struct wl_display *display)
> callback = wl_display_sync(display);
> if (callback == NULL)
> return -1;
> + wl_proxy_set_queue(callback, queue);
> wl_callback
Hi,
On Tuesday, July 15, 2014, Giulio Camuffo wrote:
> 2014-07-14 22:31 GMT+03:00 Jason Ekstrand >:
> > Guilio,
> > Would it be better to name it wl_event_queue_roundtrip and just have it
> take
> > the wl_event_queue? I guess it is sort-of a wl_display operation, but
> you
> > could argue it
Hi,
On Tuesday, July 15, 2014, Giulio Camuffo wrote:
> 2014-07-14 22:31 GMT+03:00 Jason Ekstrand >:
> > Guilio,
> > Would it be better to name it wl_event_queue_roundtrip and just have it
> take
> > the wl_event_queue? I guess it is sort-of a wl_display operation, but
> you
> > could argue it
On 5 September 2012 20:49, Bill Spitzak wrote:
> Doesn't the compositor have access to what type the surfaces are? It can
> then know the surface is opaque and ignore the opaque region there. Then if
> the client changes back to a non-opaque surface the opaque region is
> unchanged and starts bein
Hi,
On 7 September 2012 13:56, Uoti Urpala wrote:
> On Fri, 2012-08-31 at 11:04 +0200, Alexander Preisinger wrote:
>> Thanks for your input. I will try to fix the patches according to your
>> comments. As for the timer_fd stuff, it was used in weston toytoolkit and
>> I found no other way to impl
Hi,
On 11 September 2012 16:23, David Herrmann wrote:
> As there is currently no stable release of xkbcommon, other projects might
> want to include a copy of the keysyms so they can be used even though
> libxkbcommon may not be available on the machine. However, if xkbcommon.h
> is still include
Hi,
On 1 October 2012 02:08, Bill Spitzak wrote:
> On 09/30/2012 01:35 AM, Pekka Paalanen wrote:
>> You might invent elaborate schemes to overcome the latter cons,
[and this did happen]
>> but even the roundtrip argument alone is a serious one, and there
>> would have to be a serious benefit in
Hi,
On 2 October 2012 11:38, wrote:
> On 10/02, Фамилия Имя wrote:
>> switch between different keyboard layouts (languages) using both alt keys.
>> It was
>
>> https://bugs.freedesktop.org/show_bug.cgi?id=4927
>
> This mentions a fix for X would be to switch to xkbcommon. xkbcommon is
> what w
Hi,
On 2 October 2012 17:51, Ran Benita wrote:
> Well, speaking of XKB bugs, there's this one which is inherent to the
> specification:
> https://bugs.freedesktop.org/show_bug.cgi?id=865
> We might want to consider some way to properly fix this?
Indeed. I still can't think of a way to do this p
Hi,
On 3 October 2012 05:34, Bill Spitzak wrote:
> Having read the bug, it seems extremely specific to layout switching with
> shift+ctrl.
It's not.
> However there are a lot of other identical bugs that prevent
> things that are common on Windows from working on X:
>
> 1. One post mentions tha
Hi,
On 29 September 2012 19:31, Jonas Ådahl wrote:
> Ok, so what I'm trying to do is to enable what people call "smooth
> scrolling" on an input level, meaning that scrolling is not based on
> discrete arbitrary "steps" but on a more fluid motion. These types of
> events makes most sense for cert
Hi,
On 4 October 2012 17:06, Jonas Ådahl wrote:
> On Thu, Oct 4, 2012 at 12:47 AM, Daniel Stone wrote:
>> I agree it makes perfect sense, but note that axis events are already
>> fixed-point, so you already get fairly fluid motion (motion in units
>> of 1/256th of a wheel
Hi,
After three and a half years, I'm proud to announce the first grown-up
release of xkbcommon.
xkbcommon is a keymap handling library, which can parse XKB
descriptions (e.g. from xkeyboard-config), and use this to help its
users make sense of their keyboard input. Unfortunately X11's
requiremen
Hi,
On 31 October 2012 09:13, Ran Benita wrote:
> In order to use xcb_request_check(), given a request without a reply,
> you need to use the _checked() variant of the request function.
> See xcb-requests(3).
Both these patches look good to me, thanks.
Cheers,
Daniel
___
If our colour components are all less than (20 / 255), call it 0 and
move on.
Signed-off-by: Daniel Stone
---
clients/smoke.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/clients/smoke.c b/clients/smoke.c
index 42540d0..f25a657 100644
--- a/clients/smoke.c
+++ b/clients/smoke.c
XKB provides keypad symbols in a separate namespace. We don't care
about the distinction, so map them to normal symbols before starting
processing.
Signed-off-by: Daniel Stone
---
clients/terminal.c | 63
1 file changed, 63 inser
Signed-off-by: Daniel Stone
---
clients/smoke.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/clients/smoke.c b/clients/smoke.c
index 905e53f..80b8c58 100644
--- a/clients/smoke.c
+++ b/clients/smoke.c
@@ -37,7 +37,7 @@ struct smoke {
struct window *window
Split motion tracking out into separate handlers so we can have one per
touch.
Signed-off-by: Daniel Stone
---
clients/smoke.c | 155 +++
1 file changed, 110 insertions(+), 45 deletions(-)
diff --git a/clients/smoke.c b/clients/smoke.c
index
Hi all,
Here's the somewhat-delayed XWayland update for 1.0. With this and my
updated X server, I've been able to run XWayland just fine under Weston
from current git master.
The X server tree is at:
git://git.collabora.com/git/user/daniels/xserver
xwayland-1.12 is an extension of the bra
Avoids a segfault whenever we get a key event, and try to set the
cursor, dereferencing a NULL input->pointer.
Signed-off-by: Daniel Stone
---
clients/window.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/clients/window.c b/clients/window.c
index ddd8bca..288a526 100644
--
nnect.
Requires a protocol version bump.
Signed-off-by: Daniel Stone
---
protocol/xserver.xml |4 +++-
src/xwayland/launcher.c |9 +
src/xwayland/window-manager.c | 21 ++---
3 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/pro
Every single frame, we were calling the flush_damage handler in the
renderer. For GLES2 with subimage, this wasn't too bad as we'd never
call glTexSubImage2D, but without it, we'd upload the entire frame
through glTexImage2D every time.
Signed-off-by: Daniel Stone
---
src/comp
Otherwise glTexSubImage2D will reject our co-ordinates as being out of
bounds.
Signed-off-by: Daniel Stone
---
src/compositor.c |5 +
1 file changed, 5 insertions(+)
diff --git a/src/compositor.c b/src/compositor.c
index 6b0c004..d5b13c8 100644
--- a/src/compositor.c
+++ b/src
Instead of issuing draw commands immediately after we map or
reconfigure, wait for the server to send us an Expose event, thus making
sure our drawing doesn't get lost.
Signed-off-by: Daniel Stone
---
src/xwayland/window-manager.c | 218 +
1 file ch
fered surfaces.
Signed-off-by: Daniel Stone
---
src/compositor.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/src/compositor.c b/src/compositor.c
index d5b13c8..855203a 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -1258,6 +1258,8 @@ surface_commit(struct wl_client *client, s
When we're resizing from the top or left, send the new window size
through the X server as well, so it can handle the move and resize with
one atomic attach.
Signed-off-by: Daniel Stone
---
src/xwayland/window-manager.c | 39 ---
1 file change
Hi,
On 8 November 2012 04:06, Tiago Vignatti wrote:
> I was thinking only about porting XWayland for the new registry scheme and
> the surface atomic commit we've introduced in 0.95 -> 1.0. In fact, I've
> applied on X server these patches:
>
> XWayland: Add init_complete protocol
> XWayland: Po
Hi,
On 8 November 2012 08:13, Tiago Vignatti wrote:
> On 11/07/2012 06:35 PM, Daniel Stone wrote:
>>
>> Well, I think we could take all the server patches (including
>> init_complete), and drop the Expose and resize patches from Weston if
>> you like.
>>
>
&g
Hi Ander,
On 22 November 2012 00:11, Ander Conselvan de Oliveira <
ander.conselvan.de.olive...@intel.com> wrote:
> The reason for this is that the renderer's repaint function is not
> called if a client buffer is scanned out. When the surface moves to the
> scan out plane, the primary plane is da
Hi Pekka,
On 23 November 2012 18:35, Pekka Paalanen wrote:
> \Weston_surface:opaque is referenced only in the transform_disable()
> path, because we never bothered to write an algorithm for the
> transform_enable() path. A pixman region deals with axis-aligned
> rectangles, and the conversion f
Hi,
On 6 December 2012 04:43, Tiago Vignatti wrote:
> indeed. On my "less intrusive" draft of subsurface, I've first started
> brainstorming the input focus behavior [0]. That's quite useful for the
> video player example that wants some kind of input control or a dialog
> stick window that might
Hi,
On 6 December 2012 01:32, Pekka Paalanen wrote:
> Clipping
>
> The term sub-surface sounds like a sub-window, which may cause one to
> think, that it will be clipped to the parent surface area. I do not
> think we should force or even allow such clipping.
>
> Forcing the clipping would waste
On 20 December 2012 22:15, Bill Spitzak wrote:
> The big difference from X and Windows is that it is officially stated that
> the client can alter the parent pointer at any time, which avoids any needs
> for attempting to solve complex stacking issues using layers and groups or
> by having to sup
On 25 January 2013 07:17, Bill Spitzak wrote:
> ashjas wrote:
> > Thanks Bill for that info.. after searching for your patch i found this
> > discussion of what you indicated.. but i couldnot find the patch that
> > you mentioned..
> > http://lists.freedesktop.org/**archives/wayland-devel/2012-**
On 4 February 2013 17:59, Bill Spitzak wrote:
> I think what happened is that because writing an input method was not easy
> and required huge amounts of support code that was not needed to support
> simple compose or pick-character-by-number operations, these were instead
> implemented in X usin
Hi,
On 14 February 2013 17:24, Kristian Høgsberg wrote:
> On Wed, Feb 13, 2013 at 08:50:39PM +, Rune Kjær Svendsen wrote:
> > Through trial-and-error editing the config file, I've found that this is
> > caused by the "keymap_layout=en" line in weston.ini. No freeze when this
> is
> > comment
Hi,
On 15 February 2013 16:02, Fred Ollinger wrote:
> Surely there is functionality that plugin authors will want which will
> not change?
>
Yes, but exactly what that is is a far more difficult question. Help
welcome.
Cheers,
Daniel
___
wayland-dev
Hi,
On 19 February 2013 10:17, Ander Conselvan de Oliveira wrote:
> That's a tricky one. I agree that the timestamp of a frame callback does
> not represent the moment the last attached buffer reached the screen. But
> the timestamp is that of the latest completed flip.
>
> The protocol descript
Hi,
On 19 February 2013 10:31, Pekka Paalanen wrote:
> it's nice to start on this.
>
Aye, sounds good to me.
> Should we standardise on always using just $(datadir)/wayland, or
> should libwayland define the directory in its .pc file? I guess
> libwayland cannot do that, because then you cou
On 25 February 2013 20:12, Bill Spitzak wrote:
> I think you are right, that removes the race condition where the pointer
> exits before the client sends the lock. If the client wants to lock when
> the user hits a button always, it can just release on the leave event.
>
> I suppose there still i
Hi,
On 28 February 2013 20:02, Sam Spilsbury wrote:
> Because all of the data has been read from the fd, there is a
> condition where we have read every single event that needed to be
> delivered to us. Then when we return to poll (), it will block
> indefinitely because there is nothing left in
git://anongit.freedesktop.org/git/xorg/lib/libxtrans
git://anongit.freedesktop.org/xorg/proto/xineramaproto
Alternately, get the tarballs from http://www.x.org/archive/individual/
On 3 March 2013 22:08, Bill Spitzak wrote:
> With the newest version I am able to get wayland and weston to compil
On 4 March 2013 12:18, Bill Spitzak wrote:
> On 03/04/2013 08:27 AM, Daniel Stone wrote:
>
>> git://anongit.freedesktop.org/**git/xorg/lib/libxtrans<http://anongit.freedesktop.org/git/xorg/lib/libxtrans>
>> <http://anongit.freedesktop.**org/git/xorg/lib/libxtrans<
Hi,
On 22 February 2013 07:07, Pekka Paalanen wrote:
> The biggest improvement over v1 is that we have some thought-out
> commit behaviours. It is possible to resize a window so that all
> surfaces stay in sync on screen, and it is also possible to have
> sub-surfaces running on their own (i.e.
Hi,
On 9 March 2013 07:24, Scott Moreau wrote:
> diff --git a/hw/xfree86/xwayland/xwayland.c
> b/hw/xfree86/xwayland/xwayland.c
> index d97f4ee..f59bfe4 100644
> --- a/hw/xfree86/xwayland/xwayland.c
> +++ b/hw/xfree86/xwayland/xwayland.c
> @@ -344,6 +344,9 @@ void xwl_screen_post_damage(struct x
Hi,
On 18 March 2013 01:47, Yichao Yu wrote:
> On Sun, Mar 17, 2013 at 8:51 PM, Scott Moreau wrote:>
> by wayland developers that each toolkit should implement this feature
> > if they would like to have it. My position is that the key repeat
>
> And the decision was all toolkits/programs writt
Hi,
On 18 March 2013 02:55, Sylvain BERTRAND wrote:
> Another though which targets sub-surface interfaces: are the
> hardware overlays for YUV buffers that more energy efficient than
> GPU scaling/color space conversion since most the energy would be
> burned into the video decoding anyway?
Ye
On 24 March 2013 10:27, Scott Moreau wrote:
> - Working xwayland titlebar buttons
>
Did that patchset get submitted to the list for review? If not, will it be?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.
Hi,
On 24 March 2013 11:29, Scott Moreau wrote:
> On Sun, Mar 24, 2013 at 5:13 AM, Daniel Stone
> wrote:
> > On 24 March 2013 10:27, Scott Moreau wrote:
> >> - Working xwayland titlebar buttons
> >
> > Did that patchset get submitted to the list for review? If
Hi,
On 24 March 2013 19:10, Scott Moreau wrote:
> On Sun, Mar 24, 2013 at 6:17 AM, Daniel Stone
> wrote:
> > I definitely don't see it that way, and without being able to speak for
> > Kristian, I daresay he doesn't either. There's a big gap between not
>
Hi Jonas,
On 17 March 2013 09:13, Jonas Ådahl wrote:
> A logical surface is a special kind of surface that never gets its own
> buffer attached, or opaque region set etc. It is obtained by using a
> surface handle that can be shared in some way between clients. A handle
> is a server wide unique
yeah, this is why I split the events: one to provide the new_id for the
buffer, another to let the client know it was available for use, and then
all manner of private protocol in between to actually enable those target
APIs to use the buffer.
Thanks for taking a look!
Cheers,
Daniel
>
Hi,
On 30 March 2013 05:31, Matthias Clasen wrote:
> Here are a few questions/observations I had while studying the protocol
> docs:
>
> - The use of serials in events seems a bit inconsistent. Most
> wl_pointer events have serials, but axis doesn't. wl_keyboard
> enter/leave events do. wl_data_
Hi,
On 30 March 2013 13:34, Matthias Clasen wrote:
> On Sat, Mar 30, 2013 at 7:56 AM, Daniel Stone wrote:
>
>> - Various input events have a time field. The spec doesn't really say
>>> anything about this. What is it good for, and what units are these -
>>> m
Hi,
On 30 March 2013 20:40, Jason Ekstrand wrote:
> On Fri, Mar 29, 2013 at 12:02 PM, Daniel Stone
> wrote:
> > Yeah, we need to define API here. For EGL, it'd be a matter of the EGL
> > implementation sending an event in between register_buffer and
> > buffer_
Hi,
On 30 March 2013 20:48, Jason Ekstrand wrote:
> Some of this stuff has been somewhat re-defined lately and may not be
> up-to-date. You may want to talk to Kristian or Daniel and see what
> the current line-of-thought on types of compositors is. I like the
> fact that you expanded on thing
Hi,
On 30 March 2013 22:37, Jason Ekstrand wrote:
> I think this should be re-worded. It's correct, it just seems
> awkward. For example:
>
> Input events also carry timestamps in milliseconds. The base for
> these timestamps is left up to the compositor. Therefore, they should
> not be comp
Hi,
On 30 March 2013 16:55, Thiago Macieira wrote:
> On sábado, 30 de março de 2013 09.34.24, Matthias Clasen wrote:
> > > Monotonic (ideally) time in an undefined domain, i.e. they're only
> > > meaningful on relation to each other.
> >
> > What can you do with them ? For the use case that Giul
Hi,
On 1 April 2013 15:02, Eoff, Ullysses A wrote:
>
> I already submitted
> http://lists.freedesktop.org/archives/wayland-devel/2013-March/008103.html
> that does this same thing... except that it preserved the relative
> "move_pointer" logic.
One problem I can see with this is co-ordinate s
Hi,
It gives me great pleasure etc to announce xkbcommon 0.3.0. This is
mostly a bugfix and consolidation release, with no fun new features
(and no API/ABI breaks), aside from:
* a new xkb_keymap_new_from_buffer entrypoint, to support
non-NULL-terminated strings courtesy of David Herrmann, which
Hi,
On 2 April 2013 02:08, Peter Hutterer wrote:
> Create client-side and server-side man pages from doxygen. The doxygen
> config options are virtually the same as for the XML output, but we do pass
> in the specific options via stdin.
>
> WL_EXPORT is predefined to the empty string, it makes th
Hi,
On 3 April 2013 03:09, Kristian Høgsberg wrote:
> On Sat, Mar 30, 2013 at 01:31:34AM -0400, Matthias Clasen wrote:
>> - It looks like I can't trigger a popup from a key or touch event,
>> because set_popup requires a serial that corresponds to an implicit
>> pointer grab. That is sad, I like
Hi Martin,
By and large this looks good to me, although the main comment I have
is that this should probably be using the acceleration mechanism in
src/filter.c.
Cheers,
Daniel
On 29 March 2013 20:47, Martin Minarik wrote:
> Acceleration: After examining, I don't like the X acceleration
> approa
Hi Yichao,
On 3 April 2013 17:50, Yichao Yu wrote:
> On Wed, Apr 3, 2013 at 12:43 PM, Kristian Høgsberg
> wrote:
>> I can't think of anything that does this in any desktop environment
>> I've ever seen. If as usecase for this comes up we can certainly add
>> it, or any desktop environment can d
Hi,
On 3 April 2013 18:01, Yichao Yu wrote:
> Yes I am talking about menu not notification (sorry the name is status
> notifier[1] instead of status notification), which is the system tray
> protocol.
Ah OK, I see. In this case though, there's still a user input event
which triggers it, so I do
Hi,
On 8 April 2013 22:11, Kristian Høgsberg wrote:
> The problem that Pekka brought up of not sending the right timestamp
> is still not really fixable with the above structure. When the
> compositor repaints and sends out frame events it still doesn't know
> when the frame is going to be visib
Hi,
On 2 May 2013 19:06, Bill Spitzak wrote:
> Pekka Paalanen wrote:
>> So it's really a question whether we can require all compositors to
>> unconditionally support crop&scale. And that really means *all* Wayland
>> compositors forever, since wl_surface is core protocol.
>
> I see no reason not
Hi,
On 2 May 2013 15:42, Jason Ekstrand wrote:
> Ok, I see it now. Sorry, but I missed it on my first read-through. Yes, it
> fixes the problem, but in an extremely confusing way. The reason I say it
> is confusing is because it inherently mixes buffer and surface coordinate
> systems. I reall
Hi,
On 2 May 2013 10:44, Pekka Paalanen wrote:
> On Tue, 30 Apr 2013 09:14:48 -0400
> Todd Showalter wrote:
>> The question is, is a gamepad an object, or is a *set* of gamepads
>> an object?
>
> Both, just like a wl_pointer can be one or more physical mice. Whether a
> wl_pointer is backed
Hi,
On 2 May 2013 20:56, Kristian Høgsberg wrote:
> On Tue, Apr 16, 2013 at 06:19:47PM -0700, Bill Spitzak wrote:
>> I would remember the positions of styling as bytes. However the
>> renderer can render as though they are moved left to the first break
>> between glyphs (ie it will preedit-highli
Hi,
On 2 May 2013 20:33, Bill Spitzak wrote:
> Daniel Stone wrote:
>>> I also think all of wl_shell should be a core requirement.
>>
>> Not all compositors are user sessions. Think about nested compositors
>> for browsers, or capture, or also very stripped-down
Hi,
On 20 April 2013 22:13, Nick Kisialiou wrote:
> Generic device input may be too complicated to put it into Wayland protocol.
> For example, take Razer Hydra controller:
> http://www.engadget.com/2011/06/08/razer-totes-hydra-sticks-and-6400dpi-dual-sensor-mice-to-e3-2011/
>
> There are 2 USB c
Hi,
On 19 April 2013 10:18, Pekka Paalanen wrote:
> Keyboards already have extensive mapping capabilities. A Wayland server
> sends keycodes (I forget in which space exactly) and a keymap, and
> clients feed the keymap and keycodes into libxkbcommon, which
> translates them into something actuall
Hi,
On 21 April 2013 06:28, Todd Showalter wrote:
> On Fri, Apr 19, 2013 at 7:08 PM, Bill Spitzak wrote:
>> I think this is going to require pointer warping. At first I thought it
>> could be done by hiding the pointer and faking it's position, but that would
>> not stop the invisible pointer fr
Hi,
On 29 April 2013 18:44, Bill Spitzak wrote:
> Has anybody thought about pens (ie wacom tablets)? These have 5 degrees of
> freedom (most cannot distinguish rotation about the long axis of the pen).
> There are also spaceballs with full 6 degrees of freedom.
As Todd said, these really need to
1201 - 1300 of 2140 matches
Mail list logo
