[PATCH] Add api to obtain min/max keycode
From: Matthias Clasen
Users of libxkbcommon need these values to iterate over all
keycodes in the keymap.
---
src/keymap.c | 12
xkbcommon/xkbcommon.h | 20
2 files changed, 32 insertions(+)
diff --git a/src/keymap.c b/src/keymap.c
index 55000f4..14ec25f 100644
--- a/src/keymap.c
+++ b/src/keymap.c
@@ -484,6 +484,18 @@ err:
return 0;
}
+XKB_EXPORT xkb_keycode_t
+xkb_keymap_get_min_keycode (struct xkb_keymap *keymap)
+{
+return keymap->min_key_code;
+}
+
+XKB_EXPORT xkb_keycode_t
+xkb_keymap_get_max_keycode (struct xkb_keymap *keymap)
+{
+return keymap->max_key_code;
+}
+
/**
* Simple boolean specifying whether or not the key should repeat.
*/
diff --git a/xkbcommon/xkbcommon.h b/xkbcommon/xkbcommon.h
index a2aecfb..412f429 100644
--- a/xkbcommon/xkbcommon.h
+++ b/xkbcommon/xkbcommon.h
@@ -974,6 +974,26 @@ xkb_led_index_t
xkb_keymap_led_get_index(struct xkb_keymap *keymap, const char *name);
/**
+ * Get the minimum keycode of the keymap
+ *
+ * @returns The minimum keycode of the keymap.
+ *
+ * @memberof xkb_keymap
+ */
+xkb_keycode_t
+xkb_keymap_get_min_keycode (struct xkb_keymap *keymap);
+
+/**
+ * Get the maximum keycode of the keymap
+ *
+ * @returns The maximum keycode of the keymap.
+ *
+ * @memberof xkb_keymap
+ */
+xkb_keycode_t
+xkb_keymap_get_max_keycode (struct xkb_keymap *keymap);
+
+/**
* Determine whether a key should repeat or not.
*
* A keymap may specify different repeat behaviors for different keys.
--
1.8.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland] Zero out the closure serializing buffer to make valgrind happy.
Valgrind complains because sometimes padding at the ends of strings and arrays is left uninitialized. Zeroing out the buffer fixes this problem. Signed-off-by: Jason Ekstrand --- src/connection.c | 4 1 file changed, 4 insertions(+) diff --git a/src/connection.c b/src/connection.c index 9425ca6..f79b6d0 100644 --- a/src/connection.c +++ b/src/connection.c @@ -1018,6 +1018,8 @@ wl_closure_send(struct wl_closure *closure, struct wl_connection *connection) uint32_t buffer[256]; int size; + memset(buffer, 0, sizeof buffer); + if (copy_fds_to_connection(closure, connection)) return -1; @@ -1034,6 +1036,8 @@ wl_closure_queue(struct wl_closure *closure, struct wl_connection *connection) uint32_t buffer[256]; int size; + memset(buffer, 0, sizeof buffer); + if (copy_fds_to_connection(closure, connection)) return -1; -- 1.8.1.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Correctly handle extended RDP keycodes
On 09/04/2013 21:21, Kristian Høgsberg wrote: > On Sat, Apr 06, 2013 at 11:39:26PM +0200, Hardening wrote: >> The keycodes received by the FreeRDP server aren't evdev keycodes. >> This patch adds the correct convertion to evdev keycodes. After the >> patch all keys that are marked as extended in RDP packets become >> functionnal (that's the case for the windows key). >> Please note that this patch rely on some corrections that have been >> pushed on the FreeRDP github tonight. > > Is there a never version of this patch or does it rely on patches > pushed to github? Could you either squash the fixes into the patch > and resend or send all required patches to the list? > The required fixes have been merged in FreeRDP master. The patch i have sent sunday can be used directly. Hardening. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Correctly handle extended RDP keycodes
On Sat, Apr 06, 2013 at 11:39:26PM +0200, Hardening wrote:
> The keycodes received by the FreeRDP server aren't evdev keycodes.
> This patch adds the correct convertion to evdev keycodes. After the
> patch all keys that are marked as extended in RDP packets become
> functionnal (that's the case for the windows key).
> Please note that this patch rely on some corrections that have been
> pushed on the FreeRDP github tonight.
Is there a never version of this patch or does it rely on patches
pushed to github? Could you either squash the fixes into the patch
and resend or send all required patches to the list?
thanks,
Kristian
> ---
> src/compositor-rdp.c | 54
> +++---
> 1 file changed, 42 insertions(+), 12 deletions(-)
>
> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
> index 2caaa57..e50ed5b 100644
> --- a/src/compositor-rdp.c
> +++ b/src/compositor-rdp.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
>
> #include "compositor.h"
> #include "pixman-renderer.h"
> @@ -603,9 +604,10 @@ xf_peer_capabilities(freerdp_peer* client)
> return TRUE;
> }
>
> +
> struct rdp_to_xkb_keyboard_layout {
> - UINT32 rdpLayoutCode;
> - char*xkbLayout;
> + UINT32 rdpLayoutCode;
> + char *xkbLayout;
> };
>
> /* picked from
> http://technet.microsoft.com/en-us/library/cc766503(WS.10).aspx */
> @@ -621,14 +623,14 @@ static struct rdp_to_xkb_keyboard_layout
> rdp_keyboards[] = {
>
> /* taken from 2.2.7.1.6 Input Capability Set (TS_INPUT_CAPABILITYSET) */
> static char *rdp_keyboard_types[] = {
> - "", /* 0: unused */
> - "", /* 1: IBM PC/XT or compatible (83-key) keyboard */
> - "", /* 2: Olivetti "ICO" (102-key) keyboard */
> - "", /* 3: IBM PC/AT (84-key) or similar keyboard */
> + "", /* 0: unused */
> + "", /* 1: IBM PC/XT or compatible (83-key) keyboard */
> + "", /* 2: Olivetti "ICO" (102-key) keyboard */
> + "", /* 3: IBM PC/AT (84-key) or similar keyboard */
> "pc102",/* 4: IBM enhanced (101- or 102-key) keyboard */
> - "", /* 5: Nokia 1050 and similar keyboards */
> - "", /* 6: Nokia 9140 and similar keyboards */
> - "" /* 7: Japanese keyboard */
> + "", /* 5: Nokia 1050 and similar keyboards */
> + "", /* 6: Nokia 9140 and similar keyboards */
> + "" /* 7: Japanese keyboard */
> };
>
> static BOOL
> @@ -643,7 +645,6 @@ xf_peer_post_connect(freerdp_peer* client)
> struct xkb_keymap *keymap;
> int i;
>
> -
> peerCtx = (RdpPeerContext *)client->context;
> c = peerCtx->rdpCompositor;
> output = c->output;
> @@ -778,9 +779,22 @@ xf_input_synchronize_event(rdpInput *input, UINT32 flags)
> pixman_region32_fini(&damage);
> }
>
> +extern DWORD KEYCODE_TO_VKCODE_EVDEV[];
> +static uint32_t vk_to_keycode[256];
> +static void
> +init_vk_translator(void)
> +{
> + int i;
> +
> + memset(vk_to_keycode, 0, sizeof(vk_to_keycode));
> + for(i = 0; i < 256; i++)
> + vk_to_keycode[KEYCODE_TO_VKCODE_EVDEV[i] & 0xff] = i-8;
> +}
> +
> static void
> xf_input_keyboard_event(rdpInput *input, UINT16 flags, UINT16 code)
> {
> + uint32_t scan_code, vk_code, full_code;
> enum wl_keyboard_key_state keyState;
> RdpPeerContext *peerContext = (RdpPeerContext *)input->context;
> int notify = 0;
> @@ -793,9 +807,24 @@ xf_input_keyboard_event(rdpInput *input, UINT16 flags,
> UINT16 code)
> notify = 1;
> }
>
> - if(notify)
> + if(notify) {
> + full_code = code;
> + if(flags & KBD_FLAGS_EXTENDED)
> + full_code |= KBD_FLAGS_EXTENDED;
> +
> + vk_code = GetVirtualKeyCodeFromVirtualScanCode(full_code, 4);
> + if(vk_code > 0xff) {
> + weston_log("invalid vk_code %x", vk_code);
> + return;
> + }
> + scan_code = vk_to_keycode[vk_code];
> +
> +
> + /*weston_log("code=%x ext=%d vk_code=%x scan_code=%x\n", code,
> (flags & KBD_FLAGS_EXTENDED) ? 1 : 0,
> + vk_code, scan_code);*/
> notify_key(&peerContext->item.seat,
> weston_compositor_get_time(),
> - code, keyState, STATE_UPDATE_AUTOMATIC);
> + scan_code, keyState,
> STATE_UPDATE_AUTOMATIC);
> + }
> }
>
> static void
> @@ -986,6 +1015,7 @@ backend_init(struct wl_display *display, int *argc, char
> *argv[],
>
> freerdp_get_version(&major, &minor, &revision);
> weston_log("using FreeRDP version %d.%d.%d\n", major, minor, revision);
> + init_vk_translator();
>
> const struct weston_option rdp_options[] = {
> { WESTON_OPTION_BOOLEAN, "env-socket", 0, &config.env_socket },
> --
> 1.7.10.4
>
> ___
>
Re: [PATCH weston] clients: tablet-shell: Wait for set_homescreen hits the server
On Tue, Apr 09, 2013 at 11:48:06AM -0300, Tiago Vignatti wrote:
> This relates to:
> https://bugs.freedesktop.org/show_bug.cgi?id=57634
> https://bugs.freedesktop.org/show_bug.cgi?id=57637
>
> Signed-off-by: Tiago Vignatti
Thanks Tiago, that fixes both those bugs as far as I can see. It
looks like we broke that when we wl_registry was introduced, requiring
an extra round trip in the init sequence.
Kristian
> clients/tablet-shell.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/clients/tablet-shell.c b/clients/tablet-shell.c
> index f756cbc..99d66f2 100644
> --- a/clients/tablet-shell.c
> +++ b/clients/tablet-shell.c
> @@ -473,6 +473,9 @@ int main(int argc, char *argv[])
> tablet.homescreen = homescreen_create(&tablet);
> tablet_shell_set_homescreen(tablet.tablet_shell,
> window_get_wl_surface(tablet.homescreen->window));
> +
> + wl_display_roundtrip (display_get_display(tablet.display));
> +
> wl_list_init(&tablet.homescreen->launcher_list);
>
> config_file = config_file_path("weston.ini");
> --
> 1.7.9.5
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] clients: tablet-shell: Wait for set_homescreen hits the server
This relates to:
https://bugs.freedesktop.org/show_bug.cgi?id=57634
https://bugs.freedesktop.org/show_bug.cgi?id=57637
Signed-off-by: Tiago Vignatti
---
clients/tablet-shell.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/clients/tablet-shell.c b/clients/tablet-shell.c
index f756cbc..99d66f2 100644
--- a/clients/tablet-shell.c
+++ b/clients/tablet-shell.c
@@ -473,6 +473,9 @@ int main(int argc, char *argv[])
tablet.homescreen = homescreen_create(&tablet);
tablet_shell_set_homescreen(tablet.tablet_shell,
window_get_wl_surface(tablet.homescreen->window));
+
+ wl_display_roundtrip (display_get_display(tablet.display));
+
wl_list_init(&tablet.homescreen->launcher_list);
config_file = config_file_path("weston.ini");
--
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland and Weston 1.1 just around the corner
On 04/09/2013 12:13 AM, Kristian Høgsberg wrote: • XWM split out as a client. The core feature in this work was about avoiding the deadlock between X and the X WM in weston. We fixed this by making the authentication step asynchrohous instead. right. And the two immediate tasks for XWayland are: 1. "XWayland: XWM can't handle transient windows without parent": https://bugs.freedesktop.org/show_bug.cgi?id=59983 2. integration upstream; That'd be lil tricky now due the DRI2 authentication method I've introduced for Wayland against the upstream changes that prime brought together. But the upstream is a must, specially for distros that want to ship XWayland support and considering now that Wayland 1.0 is out and stable. I don't have plans to work on any of those tasks but I'm happy to give help there most definitely. Tiago ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] Make backends always specify output repaint time
On Mon, 8 Apr 2013 17:11:27 -0400
Kristian Høgsberg wrote:
> On Sun, Apr 07, 2013 at 05:24:51PM +0300, Pekka Paalanen wrote:
> > On Fri, 5 Apr 2013 23:07:11 +0200
> > Jonas Ådahl wrote:
> >
> > > Most backends relies on gettimeofday(2) for output repaint
> > > timestamps but this is not a requirement. Before this patch
> > > repaints coming from idle_repaint() always used gettimeofday(2)
> > > for timestamps. For backends not using that time source this
> > > could cause large jumps between timestamps.
> > >
> > > To fix this, timestamps needs to always come from the backend.
> > > This means that the backend needs to always be responsible of
> > > starting the repaint loop in case that the repaint cannot start
> > > immediately.
> >
> > Good idea.
> >
> > > The drm backend implementation is from the patch by Ander
> > > Conselvan de Oliveira found here:
> > > http://lists.freedesktop.org/archives/wayland-devel/2013-February/007393.html
> > >
> > > Signed-off-by: Jonas Ådahl
> > > ---
> > >
> > > Hi,
> > >
> > > This is a follow up from reviews of Ander's patch[0] from
> > > February.
> > >
> > > What is done since that patch is to implement the
> > > "start_repaint_loop" for the current backends found in weston.
> > > All but the wayland backend implementation are pretty straight
> > > forward.
> > >
> > > [0]
> > > http://lists.freedesktop.org/archives/wayland-devel/2013-February/007393.html
> > >
> > > Jonas
> > >
> > > src/compositor-drm.c | 34 ++--
> > > src/compositor-fbdev.c| 18 ++---
> > > src/compositor-headless.c | 12 --
> > > src/compositor-rdp.c | 19 +
> > > src/compositor-rpi.c | 27 ++---
> > > src/compositor-wayland.c | 97
> > > +
> > > src/compositor-x11.c | 20 +++---
> > > src/compositor.c |2 +- src/compositor.h
> > > |1 + 9 files changed, 199 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> > > index 6e0a126..49f197e 100644
> > > --- a/src/compositor-drm.c
> > > +++ b/src/compositor-drm.c
> > > @@ -623,6 +623,26 @@ drm_output_repaint(struct weston_output
> > > *output_base, }
> > >
> > > static void
> > > +drm_output_start_repaint_loop(struct weston_output *output_base)
> > > +{
> > > + struct drm_output *output = (struct drm_output *)
> > > output_base;
> > > + struct drm_compositor *compositor = (struct
> > > drm_compositor *)
> > > + output_base->compositor;
> > > + uint32_t fb_id;
> > > +
> > > + if (output->current)
> > > + fb_id = output->current->fb_id;
> > > + else
> > > + fb_id = output->original_crtc->buffer_id;
> > > +
> > > + if (drmModePageFlip(compositor->drm.fd, output->crtc_id,
> > > fb_id,
> > > + DRM_MODE_PAGE_FLIP_EVENT, output) <
> > > 0) {
> > > + weston_log("queueing pageflip failed: %m\n");
> >
> > Btw, does this cause one refresh cycle (scanout frame) delay in
> > starting the repaint loop?
>
> Previously, we repaint in an idle handler once somebody queues a
> repaint. This typically means immediately, and as such the next page
> flip will present the updated contents. With this patch, we now queue
> a pageflip, then render and pageflip. The result is going to be
> visible the next frame, so yes it does. However, this is now
> consistent with how we render in steady-state rendering mode, that is,
> what we do when the repaint loop is already running.
>
> The way the repaint loop works now maximizes the window available to
> client to submit new content at the cost of making the pipeline one
> frame deeper. By repainting the next frame right after pageflip to
> the previous frame, we give clients the remainder of the frame to
> submit new content for the frame after next. The downside is that
> when apps submit new content, the next frame is already baked and
> sitting in the pipeline.
>
> What we do now during steady state is this:
>
> V--V--V--V--->
> (time)
>
> ^evdev event arrives
>
> ^compositor sends frame event, input events
>
> ^client repaints, commits
>
> ^compositor repaints, sends frame event,
> pageflips
>
> ^content becomes visible
>
> <--> 2-3 frames lag
>
> and with Jonas' change the cold-start scenario is this:
>
> V--V--V--V--->
>
> ^client repaints, commits
>
>^compositor calls start_frame
>
> ^compositor repaints, sends frame event,
> pageflips
>
> ^content becomes visible
>
> While we add a frame of lag to this case, we do make it more
> consistent with the steady state case.
An excellent explanation!
I wish we could have t
