[ANNOUNCE] libxkbcommon 1.7.0

[Ran Benita]

libxkbcommon 1.7.0 - 2024-03-24
==

API
---

### New

- Added early detection of invalid encodings and BOM for keymaps, rules & 
Compose.
  Also added a hint that the expected encoding must be UTF-8 compatible.

### Fixes

- Updated keysyms using latest [xorgproto] (commit: 
`cd33097fc779f280925c6d6bbfbd5150f93ca5bc`):

  For the sake of compatibility, this reintroduces some deleted keysyms and
  postpones the effective deprecation of others, that landed in xkbcommon 1.6.0.

  - Additions (reverted removal):

- `XKB_KEY_dead_lowline`
- `XKB_KEY_dead_aboveverticalline`
- `XKB_KEY_dead_belowverticalline`
- `XKB_KEY_dead_longsolidusoverlay`

  - The following keysyms names remain deprecated, but are set again (i.e. as
before xkbcommon 1.6.0) as the reference names for their respective keysyms,
in order to ensure the transition to the newer names that replace them. This
affects functions such as `xkb_keymap_key_get_name` and 
`xkb_keymap_get_as_string`.

- `XKB_KEY_masculine`: is deprecated in favor of `XKB_KEY_ordmasculine`
- `XKB_KEY_guillemotleft`: is deprecated in favor of `XKB_KEY_guillemetleft`
- `XKB_KEY_guillemotright`: is deprecated in favor of 
`XKB_KEY_guillemetright`
- `XKB_KEY_dead_small_schwa`: is deprecated in favor of `XKB_KEY_dead_schwa`
- `XKB_KEY_dead_capital_schwa`: is deprecated in favor of 
`XKB_KEY_dead_SCHWA`

  Relevant upstream merge requests: [xorgproto-83], [xorgproto-84].

[xorgproto-83]: 
https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/83
[xorgproto-84]: 
https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/84

- Keysyms: Fixed inconsistent results in `xkb_keysym_from_name` when used with
  the flag `XKB_KEYSYM_CASE_INSENSITIVE`. In some rare cases it would return a
  keysym with an upper-case name instead of the expected lower-case (e.g.
  `XKB_KEY_dead_A` instead of `XKB_KEY_dead_a`).

- Keysyms: Fixed case mapping for 3 Latin 1 keysyms:

  - `XKB_KEY_ydiaeresis`
  - `XKB_KEY_mu`
  - `XKB_KEY_ssharp`

- Keysyms: Fixed `xkb_keysym_is_modifier` to detect also the following keysyms:

  - `XKB_KEY_ISO_Level5_Shift`
  - `XKB_KEY_ISO_Level5_Latch`
  - `XKB_KEY_ISO_Level5_Lock`

- Prevent recursive includes of keymap components.

- Fixed global default statements `x.y = z;` in wrong scope not raising an 
error.

  Contributed by Mikhail Gusarov

- Rules: Made newline required after `!include` line.

  Contributed by Mikhail Gusarov.

- Rules: Fixed a bug where variant indexes were ignored with the layout index
  used instead. They are practically always the same, but don't have to be.

  Contributed by @wysiwys.

- Compose: Fixed a segfault with `xkb_compose_table_iterator_next` when used on 
an
  empty table.

  Contributed by Yuichiro Hanada.

- Compose: Added check to ensure to open only regular files, not e.g. 
directories.

- Registry: Updated the DTD and always parse the “popularity” attribute.

- Fixed a few memory leaks and keymap symbols parsing.

Tools
-

### New

- `xkbcli compile-compose`: added new CLI utility to test Compose files.
- `xkbcli interactive-evdev`: added `--verbose` option.
- `xkbcli interactive-x11`: added support for Compose.
- `xkbcli interactive-wayland`: added support for Compose.

### Fixes

- Bash completion: Fixed completion in some corner cases.

Build system


- Fix building with clang when using `-Wl,--gc-sections`.

  Contributed by ppw0.

- Fixed linking using `lld 1.17`.

  Contributed by Baptiste Daroussin.

- Fix building X11 tests on macOS.

- Documentation is no longer built by default; it requires `-Denable-docs=true`.

Tarball:


git tag: xkbcommon-1.7.0

https://xkbcommon.org/download/libxkbcommon-1.7.0.tar.xz

SHA-256: 65782f0a10a4b455af9c6baab7040e2f537520caa2ec2092805cdfd36863b247 
libxkbcommon-1.7.0.tar.xz

Wismill, Peter & Ran

[ANNOUNCE] libxkbcommon 1.6.0

[Ran Benita]

This release contains the accumulated changes to xkbcommon from the last ~year.
I'm happy to announce we are joined by a new maintainer, Pierre Le Marre
(Wismill), who wrote the majority of features, bug fixes and documentation
improvements in this release, with very high care and quality. Welcome Pierre!

libxkbcommon 1.6.0
==

API
---

### Breaking changes

- *Remove* keysyms that were intended for German T3 layout but are unused:

  - `XKB_KEY_dead_lowline`
  - `XKB_KEY_dead_aboveverticalline`
  - `XKB_KEY_dead_belowverticalline`
  - `XKB_KEY_dead_longsolidusoverlay`

  See the upstream
  [`xorgproto` 
MR](https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/70).
  See hereinafter for further changes related to keysyms.

### New

- Add Compose iterator API to iterate the entries in a compose table:

  - `xkb_compose_table_entry_sequence`
  - `xkb_compose_table_entry_keysym`
  - `xkb_compose_table_entry_utf8`
  - `xkb_compose_table_iterator_new`
  - `xkb_compose_table_iterator_free`
  - `xkb_compose_table_iterator_next`

- *Structured log messages* with a message registry. There is an *ongoing* work
  to assign unique identifiers to log messages and add a corresponding error
  index documentation page:

  - The log entries are preceded with an identifier in the form `XKB-NNN`,
where `NNN` is a decimal number.

  - The log entries can then be parsed with third-party tools, to check for
specific identifiers.

  - The new documentation page “**Error index**” lists all the kind of error
messages with their identifiers. The aim is that each entry could present
detailed information on the error and how to fix it.

- Add a new warning for numeric keysyms references in XKB files: the preferred
  keysym reference form is its name or its Unicode value, if relevant.

- Add the upper bound `XKB_KEYSYM_MAX` to check valid keysyms.

- Add a warning when loading a keymap using RMLVO with no layout but with the
  variant set. The variant is actually discarded and both layout and variant
  are set to default values, but this was done previously with no warning,
  confusing end users.

- Add support for `modifier_map None { … }`. This feature is missing compared
  to the X11 implementation. It allows to reset the modifier map of a key.

- Update keysyms using latest [xorgproto]
  (commit: `1c8128d72df22843a2022576850bc5ab5e3a46ea`):

  - Additions:

- `XKB_KEY_ordmasculine` ([xorgproto-68])
- `XKB_KEY_guillemetleft` ([xorgproto-68])
- `XKB_KEY_guillemetright` ([xorgproto-68])
- `XKB_KEY_dead_schwa` ([xorgproto-78])
- `XKB_KEY_dead_SCHWA` ([xorgproto-78])
- `XKB_KEY_dead_hamza` ([xorgproto-71])
- `XKB_KEY_XF86EmojiPicker` ([xorgproto-44])
- `XKB_KEY_XF86Dictate` ([xorgproto-49])
- `XKB_KEY_XF86CameraAccessEnable` ([xorgproto-82])
- `XKB_KEY_XF86CameraAccessDisable` ([xorgproto-82])
- `XKB_KEY_XF86CameraAccessToggle` ([xorgproto-82])
- `XKB_KEY_XF86NextElement` ([xorgproto-82])
- `XKB_KEY_XF86PreviousElement` ([xorgproto-82])
- `XKB_KEY_XF86AutopilotEngageToggle` ([xorgproto-82])
- `XKB_KEY_XF86MarkWaypoint` ([xorgproto-82])
- `XKB_KEY_XF86Sos` ([xorgproto-82])
- `XKB_KEY_XF86NavChart` ([xorgproto-82])
- `XKB_KEY_XF86FishingChart` ([xorgproto-82])
- `XKB_KEY_XF86SingleRangeRadar` ([xorgproto-82])
- `XKB_KEY_XF86DualRangeRadar` ([xorgproto-82])
- `XKB_KEY_XF86RadarOverlay` ([xorgproto-82])
- `XKB_KEY_XF86TraditionalSonar` ([xorgproto-82])
- `XKB_KEY_XF86ClearvuSonar` ([xorgproto-82])
- `XKB_KEY_XF86SidevuSonar` ([xorgproto-82])
- `XKB_KEY_XF86NavInfo` ([xorgproto-82])

  - Deprecations:

- `XKB_KEY_masculine`: use `XKB_KEY_ordmasculine` instead ([xorgproto-68])
- `XKB_KEY_guillemotleft`: use `XKB_KEY_guillemetleft` instead 
([xorgproto-68])
- `XKB_KEY_guillemotright`: use `XKB_KEY_guillemetright` instead 
([xorgproto-68])
- `XKB_KEY_dead_small_schwa`: use `XKB_KEY_dead_schwa` instead 
([xorgproto-78])
- `XKB_KEY_dead_capital_schwa`: use `XKB_KEY_dead_SCHWA` instead 
([xorgproto-78])

  [xorgproto]: https://gitlab.freedesktop.org/xorg/proto/xorgproto
  [xorgproto-44]: 
https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/44
  [xorgproto-49]: 
https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/49
  [xorgproto-68]: 
https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/68
  [xorgproto-71]: 
https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/71
  [xorgproto-78]: 
https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/78
  [xorgproto-82]: 
https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/82

- Ongoing work to improve the documentation about XKB and its V1 format.

### Fixes

- Prevent `xkb_keysym_from_name` to parse out-of-range hexadecimal keysyms.

- Disallow producing NULL character with escape sequences `\0` and `\x0`.

- Prevent overflow of octal escape 

[ANNOUNCE] libxkbcommon 1.5.0

[Ran Benita]

libxkbcommon 1.5.0
==

- Add `xkb_context` flag `XKB_CONTEXT_NO_SECURE_GETENV` and `rxkb_context` flag
  `RXKB_CONTEXT_NO_SECURE_GETENV`.

  xkbcommon uses `getenv_secure()` to obtain environment variables. This flag
  makes xkbcommon use `getenv()` instead.

  This is useful for some clients that have relatively benign capabilities set,
  like CAP_SYS_NICE, that also want to use e.g. the XKB configuration from the
  environment and user configs in XDG_CONFIG_HOME.

  Contributed by Ronan Pigott.

- Fix crash in `xkbcli interactive-wayland` under a compositor which supports
  new versions of the xdg-shell protocol.

  Contributed by Jan Alexander Steffens (heftig).

- Fix some MSVC build issues.

- Fix some issues when including xkbcommon as a meson subproject.

- meson>=0.51 is now required.

- New API:
  XKB_CONTEXT_NO_SECURE_GETENV
  RXKB_CONTEXT_NO_SECURE_GETENV


Tarball:


git tag: xkbcommon-1.5.0

https://xkbcommon.org/download/libxkbcommon-1.5.0.tar.xz

SHA-256: 560f11c4bbbca10f495f3ef7d3a6aa4ca62b4f8fb0b52e7d459d18a26e46e017 
libxkbcommon-1.5.0.tar.xz

Ran

[ANNOUNCE] libxkbcommon 1.3.1

[Ran Benita]

libxkbcommon 1.3.1 
==

- In `xkbcli interactive-x11`, use the Esc keysym instead of the Esc keycode
  for quitting.

  Contributed by Simon Ser.

- In `xkbcli how-to-type`, add `--keysym` argugment for how to type a keysym
  instead of a Unicode codepoint.

- Fix a crash in `xkb_x11_keymap_new_from_device` error handling given some
  invalid keymaps. Regressed in 1.2.0.

  Reported by Zack Weinberg. Tested by Uli Schlachter.

Tarball:


git tag: xkbcommon-1.3.1

https://xkbcommon.org/download/libxkbcommon-1.3.1.tar.xz

SHA-256: b3c710d27a2630054e1e1399c85b7f330ef03359b460f0c1b3b587fd01fe9234 
libxkbcommon-1.3.1.tar.xz

Ran

[ANNOUNCE] libxkbcommon 1.3.0

[Ran Benita]

libxkbcommon 1.3.0 
==

- Change `xkbcli list` to output YAML, instead of the previous ad-hoc format.

  This allows to more easily process the information in a programmatic way, for
  example

xkbcli list | yq -r ".layouts[].layout"

  Contributed by Peter Hutterer.

- Optimize a certain part of keymap compilation (atom interning).

- Fix segmentation fault in case-insensitive `xkb_keysym_from_name` for certain
  values like the empty string.

  Contributed by Isaac Freund.

- Support building libxkbcommon as a meson subproject.

  Contributed by Adrian Perez de Castro.

- Add `ftruncate` fallback for `posix_fallocate` in `xkbcli interactive-wayland`
  for FreeBSD.

  Contributed by Evgeniy Khramtsov.

- Properly export library symbols in MSVC.

  Contributed by Adrian Perez de Castro.

Tarball:


git tag: xkbcommon-1.3.0

https://xkbcommon.org/download/libxkbcommon-1.3.0.tar.xz
SHA256: 7b09e098ea69bc3054f0c57a9a25fda571c4df22398811606e32b5fffeb75e7b 
libxkbcommon-1.3.0.tar.xz

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon 1.2.1

[Ran Benita]

libxkbcommon 1.2.1
=

- Fix `xkb_x11_keymap_new_from_device()` failing when the keymap contains key
  types with missing level names, like the one used by the `numpad:mac` option
  in xkeyboard-config. Regressed in 1.2.0.

Tarball:


git tag: xkbcommon-1.2.1

https://xkbcommon.org/download/libxkbcommon-1.2.1.tar.xz
SHA256: e833a7d3024c9bb9d5eb2b20f6d5de08865541f21bb7ba227c83cbd236691fb3 
libxkbcommon-1.2.1.tar.xz

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon 1.2.0

[Ran Benita]

libxkbcommon 1.2.0
==

- `xkb_x11_keymap_new_from_device()` is much faster. It now performs only 2
  roundtrips to the X server, instead of dozens (in first-time calls).

  Contributed by Uli Schlachter.

- Case-sensitive `xkb_keysym_from_name()` is much faster.

- Keysym names of the form `0x12AB` and `U12AB` are parsed more strictly.
  Previously the hexadecimal part was parsed with `strtoul()`, now only up
  to 8 hexadecimal digits (0-9A-Fa-f) are allowed.

- Compose files now have a size limit (65535 internal nodes). Further sequences
  are discarded and a warning is issued.

- Compose table loading (`xkb_compose_table_new_from_locale()` and similar) is
  much faster.

- Use `poll()` instead of `epoll()` for `xlbcli interactive-evdev`, making it
  portable to FreeBSD which provides evdev but not epoll. On FreeBSD, remember
  to install the `evdev-proto` package to get the evdev headers.

- The build now requires a C11 compiler (uses anonymous structs/unions).

Tarball:


git tag: xkbcommon-1.2.0

https://xkbcommon.org/download/libxkbcommon-1.2.0.tar.xz
SHA256: 8fd678f2b2205d99dba9922e15d470a23f91cffa01cee44ba1775bfc58383a9a 
libxkbcommon-1.2.0.tar.xz

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon 1.1.0

[Ran Benita]

Note: the https://xkbcommon.org website is not updated yet with the tarball and 
documentation for this release, while we're sorting out some issues. Instead
the tarball was uploaded to GitHub. Sorry for the inconvenience.

libxkbcommon 1.1.0
==

- Publish the `xkb-format-text-v1.md` file in the HTML documentation. This file
  existed for a long time but only in the Git repository.
  Link: https://xkbcommon.org/doc/current/md_doc_keymap_format_text_v1.html

- Add partial documentation for xkb_symbols to xkb-format-text-v1.md.

  Contributed by Simon Zeni.

- Update keysym definitions to latest xorgproto. In particular, this adds many
  special keysyms corresponding to Linux evdev keycodes.

  Contributed by Peter Hutterer <@who-t.net>.

- New API:
  Too many XKB_KEY_* definitions to list here.

Tarball:


git tag: xkbcommon-1.1.0

https://github.com/xkbcommon/libxkbcommon/releases/download/xkbcommon-1.1.0/libxkbcommon-1.1.0.tar.xz
SHA256: 412cfcca596f92914ea1a66ad244804d73a5ff20b6d86459951e7ad20576c246 
libxkbcommon-1.1.0.tar.xz

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon 1.0.3

[Ran Benita]

libxkbcommon 1.0.3
==

- Fix (hopefully) a segfault in xkb_x11_keymap_new_from_device() in some
  unclear situation (bug introduced in 1.0.2).

- Fix keymaps created with xkb_x11_keymap_new_from_device() don't have level
  names (bug introduced in 0.8.0).

Tarball:


git tag: xkbcommon-1.0.3

https://xkbcommon.org/download/libxkbcommon-1.0.3.tar.xz 

SHA256: a2202f851e072b84e64a395212cbd976ee18a8ee602008b0bad02a13247dbc52 
libxkbcommon-1.0.3.tar.xz

Ran___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon 1.0.2

[Ran Benita]

libxkbcommon 1.0.2
===

- Fix a bug where a keysym that cannot be resolved in a keymap gets compiled to
  a garbage keysym. Now it is set to XKB_KEY_NoSymbol instead.

- Improve the speed of xkb_x11_keymap_new_from_device() on repeated calls in the
  same xkb_context().

Tarball:


git tag: xkbcommon-1.0.2

https://xkbcommon.org/download/libxkbcommon-1.0.2.tar.xz
SHA256: 0ea2f88f4472bbf8170c5a7112f5af8848a908ca15df9e9086c3de0189612b2b 
libxkbcommon-1.0.2.tar.xz

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon 1.0.1

[Ran Benita]

This is a fixup release to 1.0.0 to fix a failing test.

libxkbcommon 1.0.1
==

- Fix the tool-option-parsing test failing.

- Remove requirement for pytest in the tool-option-parsing test.

- Make the table output of `xkbcli how-to-type` aligned.

- Some portability and test isolation fixes.

Tarball:


git tag: xkbcommon-1.0.1

https://xkbcommon.org/download/libxkbcommon-1.0.1.tar.xz 

SHA256: ab68b25341c99f2218d7cf3dad459c1827f411219901ade05bbccbdb856b6c8d 
libxkbcommon-1.0.1.tar.xz

Ran___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon 1.0.0

[Ran Benita]

xkbcommon had its first commit on Jan 13, 2009, and its first release
with the current API on Oct 24, 2012. Since then, the API and ABI have
been stable. So it seems about time to call it 1.0.0!

This release contains a lot of work by Peter to start and fix a longstanding
deficiency of XKB -- that making any local customizations to the keyboard
layout required changing system-managed files. Now it is possible to add
custom layouts and options at the system (/etc) and user (~/.config) level,
at least when libxkbcommon is in use.

You can read more about it here:
https://xkbcommon.org/doc/current/md_doc_user-configuration.html

A new component library, libxkbregistry, makes part of this possible. Its
API is described here:
https://xkbcommon.org/doc/current/group__registry.html

We also have a new `xkbcli` command-line tool which makes it easy to debug
layouts and various other utilities.

See the full NEWS and tarball below.

libxkbcommon 1.0.0
==

Note: this release is API and ABI compatible with previous releases -- the
major version bump is only an indication of stability.

- Add libxkbregistry as configure-time optional library. libxkbregistry is a C
  library that lists available XKB models, layouts and variants for a given
  ruleset. This is a separate library (libxkbregistry.so, pkgconfig file
  xkbregistry.pc) and aimed at tools that provide a listing of available
  keyboard layouts to the user. See the Documentation for details on the API.

  Contributed by Peter Hutterer <@who-t.net>.

- Better support custom user configuration:

* Allow including XKB files from other paths.

  Previously, a 'symbols/us' file in path A would shadow the same file in
  path B. This is suboptimal, we rarely need to hide the system files - we
  care mostly about *extending* them. By continuing to check other lookup
  paths, we make it possible for a XDG_CONFIG_HOME/xkb/symbols/us file to
  have sections including those from /usr/share/X11/xkb/symbols/us.

  Note that this is not possible for rules files, which need to be manually
  controlled to get the right bits resolved.

* Add /etc/xkb as extra lookup path for system data files.

  This completes the usual triplet of configuration locations available for
  most processes:
  - vendor-provided data files in /usr/share/X11/xkb
  - system-specific data files in /etc/xkb
  - user-specific data files in $XDG_CONFIG_HOME/xkb

  The default lookup order user, system, vendor, just like everything else
  that uses these conventions.

  For include directives in rules files, the '%E' resolves to that path.

* Add a new section to the documentation for custom user configuration.

  Contributed by Peter Hutterer <@who-t.net>.

- Add an `xkbcli` command-line utility.

  This tool offers various subcommands for introspection and debugging.
  Currently the available subcommands are:

  list
List available rules, models, layouts, variants and options

  interactive-wayland
Interactive debugger for XKB keymaps for Wayland

  interactive-x11
Interactive debugger for XKB keymaps for X11

  interactive-evdev
Interactive debugger for XKB keymaps for evdev (Linux)

  compile-keymap
Compile an XKB keymap

  how-to-type
See separate entry below.

  See the manpages for usage information.

  Contributed by Peter Hutterer <@who-t.net>.

- Add `xkb_utf32_to_keysym()` to translate a Unicode codepoint to a keysym.
  When a special keysym (`XKB_KEY_` constant) for the codepoint exists, it is
  returned, otherwise the direct encoding is used, if permissible.

  Contributed by Jaroslaw Kubik <@froglogic.com>.

- Add `xkb_keymap_key_get_mods_for_level()` which retrieves sets of modifiers
  which produce a given shift level in a given key+layout.

  Contributed by Jaroslaw Kubik <@froglogic.com>.

- Add `xkbcli how-to-type` command, which, using `xkb_utf32_to_keysym()`
  and `xkb_keymap_key_get_mods_for_level()` and other APIs, prints out all
  the ways to produce a given keysym.

  For example, how to type `?` (codepoint 63) in a us,de keymap?

$ xkbcli how-to-type --layout us,de 63 | column -ts $'\t'
keysym: question (0x3f)
KEYCODE  KEY NAME  LAYOUT#  LAYOUT NAME   LEVEL#  MODIFIERS
20   AE11  2German2   [ Shift ]
20   AE11  2German2   [ Shift Lock ]
61   AB10  1English (US)  2   [ Shift ]

- Add a new section to the documentation describing the format of the XKB
  rules file.

- Search for Compose in $XDG_CONFIG_HOME/XCompose (fallback to
  ~/.config/XCompose) before trying $HOME/.XCompose.

  Note that libX11 still only searches in $HOME/.XCompose.

  Contributed by Emmanuel Gil Peyrot <@linkmauve.fr>.

- Bump meson requirement to >= 0.49.0.

- Fix build with byacc.

- Fix building X11 tests on PE targets.

  Contributed by Jon Turney <@dronecode.org.uk>

- The tests no longer rely on 

[ANNOUNCE] libxkbcommon 0.10.0

[Ran Benita]

libxkbcommon 0.10.0
===

- (security) Fix quadratic complexity in the XKB file parser. See commit
  message 7c42945e04a2107827a057245298dedc0475cc88 for details.

- Add $XDG_CONFIG_HOME/xkb to the default search path. If $XDG_CONFIG_HOME
  is not set, $HOME/.config/xkb is used. If $HOME is not set, the path is not
  added.

  The XDG path is looked up before the existing default search path $HOME/.xkb.

  Contributed by Peter Hutterer <@who-t.net>.

- Add support for include statements in XKB rules files.

  This is a step towards making local XKB customizations more tenable and
  convenient, without modifying system files.

  You can now include other rules files like this:

  ! include %S/evdev

  Two directives are supported, %H to $HOME and %S for the system-installed
  rules directory (usually /usr/share/X11/xkb/rules).

  See commit message ca033a29d2ca910fd17b1ae287cb420205bdddc8 and
  doc/rules-format.txt in the xkbcommon source code for more information.

  Contributed by Peter Hutterer <@who-t.net>.

- Downgrade "Symbol added to modifier map for multiple modifiers" log to a
  warning.

  This error message was too annoying to be shown by default. When working on
  keymaps, set `XKB_LOG_LEVEL=debug XKB_LOG_VERBOSITY=10` to see all possible
  messages.

- Support building on Windows using the meson MSVC backend.

  Contributed by Adrian Perez de Castro <@igalia.com>.

- Fix bug where the merge mode only applied to the first vmod in a
  `virtual_modifiers` statement. Given

  augment virtual_modifiers NumLock,Alt,LevelThree

  Previously it was incorrectly treated as

  augment virtual_modifiers NumLock;
  virtual_modifiers Alt;
  virtual_modifiers LevelThree;

  Now it is treated as

  augment virtual_modifiers NumLock;
  augment virtual_modifiers Alt;
  augment virtual_modifiers LevelThree;

- Reject interpret modifier predicate with more than one value. Given

  interpret ISO_Level3_Shift+AnyOf(all,extraneous) { ... };

  Previously, extraneous (and further) was ignored. Now it's rejected.

- Correctly handle capitalization of the ssharp keysym.

- Speed up and improve the internal `xkeyboard-config` tool. This tool
  compiles all layout/variant combinations in the xkeyboard-config dataset
  and reports any issues it finds.

  Contributed by Peter Hutterer <@who-t.net>.

- Speed up "atoms" (string interning). This code goes back at least to X11R1
  (released 1987).


Tarball:


git tag: xkbcommon-0.10.0

https://xkbcommon.org/download/libxkbcommon-0.10.0.tar.xz
SHA256 57c3630cdc38fb4734cd57fa349e92244f5ae3862813e533cedbd86721a0b6f2 
libxkbcommon-0.10.0.tar.xz

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon 0.9.1

[Ran Benita]

This is a fixup release to address the issue reported in 
https://bugs.archlinux.org/task/64191.

libxkbcommon 0.9.1
==

- Fix context creation failing when run in privileged processes as defined by
  `secure_getenv(3)`, e.g. GDM.

Tarball:


git tag: xkbcommon-0.9.1

https://xkbcommon.org/download/libxkbcommon-0.9.1.tar.xz
SHA256  d4c6aabf0a5c1fc616f8a6a65c8a818c03773b9a87da9fbc434da5acd1199be0 
libxkbcommon-0.9.1.tar.xz

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon 0.9.0

[Ran Benita]

libxkbcommon 0.9.0
==

- Move ~/.xkb to before XKB_CONFIG_ROOT (the system XKB path, usually
  /usr/share/X11/xkb) in the default include path. This enables the user
  to have full control of the keymap definitions, instead of only augmenting
  them.

  NOTE: We are also considering adding $XDG_CONFIG_HOME/xkb to the default
  search path, possibly replacing ~/.xkb. If you have any thoughts, let us
  know here or at https://github.com/xkbcommon/libxkbcommon/issues/112.

- Remove the Autotools build system. Use the meson build system instead.

  NOTE: The tarball for this release was created with `meson dist`; in previous
  releases we used Autotools' `make distcheck`. The main difference is that
  meson just creates a git archive and doesn't include files generated by
  bison. So now bison (or equivalent) are strictly required when building from
  the tarball.

- Fix invalid names used for levels above 8 when dumping keymaps. Previously,
  e.g. "Level20" was dumped, but only up to "Level8" is accepted by the
  parser. Now "20" is dumped.

- Change level references to always be dumped as e.g. "5" instead of "Level5".

  Change group references to always be dumped capitalized e.g. "Group3" instead
  of "group3". Previously it was inconsistent.

  These changes affect the output of xkb_keymap_get_as_string().

- Fix several build issues on macOS/Darwin, Solaris, NetBSD, cross compilation.

- Port the interactive-wayland test program to the stable version of xdg-shell.


Tarball:


git tag: xkbcommon-0.9.0

https://xkbcommon.org/download/libxkbcommon-0.9.0.tar.xz
a51885adff1f6207ad291a57c41919048fb4e5ec5b19e8e17b8c0e9a7a2746fc 
libxkbcommon-0.9.0.tar.xz

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon 0.8.4

[Ran Benita]

This is a small patch release to fix a couple of build issues.

libxkbcommon 0.8.4
==

- Fix build of xkbcommon-x11 static library with meson.

- Fix building using meson from the tarball generated by autotools.


Tarball:


git tag: xkbcommon-0.8.4

https://xkbcommon.org/download/libxkbcommon-0.8.4.tar.xz
MD5:3c4409058dfd203f641a563358e0187d  libxkbcommon-0.8.4.tar.xz
SHA1:   0ce9df42239d451f61b2112c6ba8d0a1a0879009  libxkbcommon-0.8.4.tar.xz
SHA256: 60ddcff932b7fd352752d51a5c4f04f3d0403230a584df9a2e0d5ed87c486c8b  
libxkbcommon-0.8.4.tar.xz

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon 0.8.3

[Ran Benita]

Build note: We've had a report that the autotools build doesn't work with
the new version of Bison, 3.3. If this happens to you, please switch to
using meson. The autotools build will be removed in libxkbcommon 0.9.0.

libxkbcommon 0.8.3
==

- Fix build of static libraries with meson.

- New API:
  XKB_KEY_XF86MonBrightnessCycle
  XKB_KEY_XF86RotationLockToggle

Tarball:


git tag: xkbcommon-0.8.3

https://xkbcommon.org/download/libxkbcommon-0.8.3.tar.xz
MD5:8225a206e00c4146d2e06f5e688b28e7  libxkbcommon-0.8.3.tar.xz
SHA1:   98efddc6b1d306f61b7786861730ad65a178f71a  libxkbcommon-0.8.3.tar.xz
SHA256: b855c629849a97ab9835a4ad99d6b749a636f70d38a03f070c6ef72024825540  
libxkbcommon-0.8.3.tar.xz

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Which package install locale files for xkb in wayland system?

[Ran Benita]

> Which package provides locale data?

Unfortunately the locale data is indeed provided in the libx11
repository. It would have been nice to have an "xlocale-data" package
but I was not able to push this through.

For now, my recommendation for distributions is to split the static
data in libx11 to its own package. In Debian and Ubuntu for example,
installing the split libx11-data package is sufficient (see
https://packages.debian.org/stretch/all/libx11-data/filelist). This
package does not pull any X11 dependencies.

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon 0.8.2

[Ran Benita]

libxkbcommon 0.8.2
==

- Fix various problems found with fuzzing (see commit messages for
  more details):

- Fix a few NULL-dereferences, out-of-bounds access and undefined behavior
  in the XKB text format parser.

Tarball:


git tag: xkbcommon-0.8.2

https://xkbcommon.org/download/libxkbcommon-0.8.2.tar.xz
MD5:5f7f8533f907ebcfb1cf8dceb9501264  libxkbcommon-0.8.2.tar.xz
SHA1:   5589b09b8490392573bba5527cc0cc82824028b1  libxkbcommon-0.8.2.tar.xz
SHA256: 7ab8c4b3403d89d01898066b72cb6069bddeb5af94905a65368f671a026ed58c  
libxkbcommon-0.8.2.tar.xz

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon 0.8.1

[Ran Benita]

libxkbcommon 0.8.1
==

- Fix various problems found in the meson build (see commit messages for more
  details):

- Fix compilation on Darwin.

- Fix compilation of the x11 tests and demos when XCB is installed in a
  non-standard location.

- Fix xkbcommon-x11.pc missing the Requires specification.

- Fix various problems found with fuzzing and Coverity (see commit messages for
  more details):

- Fix stack overflow in the XKB text format parser when evaluating boolean
  negation.

- Fix NULL-dereferences in the XKB text format parser when some unsupported
  tokens appear (the tokens are still parsed for backward compatibility).

- Fix NULL-dereference in the XKB text format parser when parsing an
  xkb_geometry section.

- Fix an infinite loop in the Compose text format parser on some inputs.

- Fix an invalid free() when using multiple keysyms.

- Replace the Unicode characters for the leftanglebracket and rightanglebracket
  keysyms from the deprecated LEFT/RIGHT-POINTING ANGLE BRACKET to
  MATHEMATICAL LEFT/RIGHT ANGLE BRACKET.

- Reject out-of-range Unicode codepoints in xkb_keysym_to_utf8 and
  xkb_keysym_to_utf32.


Tarball:


git tag: xkbcommon-0.8.1

https://xkbcommon.org/download/libxkbcommon-0.8.1.tar.xz
MD5:890da32b01f7cd48414e6428b6f44e64  libxkbcommon-0.8.1.tar.xz
SHA1:   0c38d160120e79e6d0d49e1c83b73bcbd6b02335  libxkbcommon-0.8.1.tar.xz
SHA256: 8d1df6bdf216950da611e66cff1af576710aad79772de3be6e131019f761f897  
libxkbcommon-0.8.1.tar.xz


Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon 0.8.0

[Ran Benita]

libxkbcommon 0.8.0
==

- Added xkb_keysym_to_{upper,lower} to perform case-conversion directly on
  keysyms. This is useful in some odd cases, but working with the Unicode
  representations should be preferred when possible.

- Added Unicode conversion rules for the signifblank and permille keysyms.

- Fixed a bug in the parsing of XKB key type definitions where the number
  of levels were determined by the number of level *names*. Keymaps which
  omit level names were hence miscompiled.

  This regressed in version 0.4.3. Keymaps from xkeyboard-config were not
  affected since they don't omit level names.

- New API:
  xkb_keysym_to_upper()
  xkb_keysym_to_lower()


Tarball:


git tag: xkbcommon-0.8.0

https://xkbcommon.org/download/libxkbcommon-0.8.0.tar.xz
MD5:7d0e4c4a137d0ac45bf6b328c84c3a81  libxkbcommon-0.8.0.tar.xz
SHA1:   2bdd5871e5e76f2fc427911f137aa46e91abbcf3  libxkbcommon-0.8.0.tar.xz
SHA256: e829265db04e0aebfb0591b6dc3377b64599558167846c3f5ee5c5e53641fe6d  
libxkbcommon-0.8.0.tar.xz


Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon 0.7.2

[Ran Benita]

libxkbcommon 0.7.2
==

- Added a Meson build system as an alternative to existing autotools build
  system.

  The intent is to remove the autotools build in one of the next releases.
  Please try to convert to it and report any problems.

  See http://mesonbuild.com/Quick-guide.html for basic usage, the
  meson_options.txt for the project-specific configuration options,
  and the PACKAGING file for more details.

  There are some noteworthy differences compared to the autotools build:

  - Feature auto-detection is not performed. By default, all features are
enabled (currently: docs, x11, wayland). The build fails if any of
the required dependencies are not available. To disable a feature,
pass -Denable-=false to meson.

  - The libraries are either installed as shared or static, as specified
by the -Ddefault_library=shared/static option. With autotools, both
versions are installed by default.

  - xorg-util-macros is not used.

  - A parser generator (bison/byacc) is always required - there is no
fallback to pre-generated output bundled in the tarball, as there is
in autotools.

- Removed Android.mk support.

- Removed the *-uninstalled.pc pkgconfig files.

- Ported the interactive-wayland demo program to v6 of the xdg-shell
  protocol.

- Added new keysym definitions from xproto.

- New API:
  XKB_KEY_XF86Keyboard
  XKB_KEY_XF86WWAN
  XKB_KEY_XF86RFKill
  XKB_KEY_XF86AudioPreset


Tarballs:


git tag: xkbcommon-0.7.2

https://xkbcommon.org/download/libxkbcommon-0.7.2.tar.xz
MD5:f53fa65beb5ae4b6a6b7f08f9dedabc4  libxkbcommon-0.7.2.tar.xz
SHA1:   782c8eab3f5daaccc151e2a9f234456997b57d04  libxkbcommon-0.7.2.tar.xz
SHA256: 28a4dc2735863bec2dba238de07fcdff28c5dd2300ae9dfdb47282206cd9b9d8  
libxkbcommon-0.7.2.tar.xz


Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon 0.7.1

[Ran Benita]

A small fixup release.

libxkbcommon 0.7.1
==

- Fixed various reported problems when the current locale is tr_TR.UTF-8.

  The function xkb_keysym_from_name() used to perform case-insensitive
  string comparisons in a locale-dependent way, but required it to to
  work as in the C/ASCII locale (the so called "Turkish i problem").

  The function is now no longer affected by the current locale.

- Fixed compilation in NetBSD.


Tarballs:


git tag: xkbcommon-0.7.1

https://xkbcommon.org/download/libxkbcommon-0.7.1.tar.xz
MD5:947ba609cb0239b9462127d5cf8908ee  libxkbcommon-0.7.1.tar.xz
SHA1:   6c0007a0206cd8bc1fa68f50aa86627d669282a2  libxkbcommon-0.7.1.tar.xz
SHA256: ba59305d2e19e47c27ea065c2e0df96ebac6a3c6e97e28ae5620073b6084e68b  
libxkbcommon-0.7.1.tar.xz

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v2] clients: Add XKB compose key support

[Ran Benita]

On Fri, Oct 07, 2016 at 12:56:00PM -0700, Bryce Harrington wrote:
> On Fri, Oct 07, 2016 at 02:48:41PM +0300, Ran Benita wrote:
> > > + /* Look up the appropriate locale, or use "C" as default */
> > > + locale = getenv("LC_ALL");
> > > + if (!locale)
> > > + locale = "C";
> > 
> > Is there a reason why you decided not to use the "full" procedure, i.e.
> > also try LC_CTYPE and LANG?
> 
> No particular reason.  I did wonder if it would be worthwhile to check
> those too, but wasn't sure what order they should be checked.  Should it
> be LANG first, then LC_CTYPE, and then fallback to LC_ALL?

I got the order from locale(7):

If the second argument to setlocale(3) is an empty string, "",
for the default locale, it is determined using the following
steps:

1. If there is a non-null environment variable LC_ALL, the
   value of LC_ALL is used.

2. If  an  environment variable with the same name as one of
   the categories above exists and is non-null, its value is
   used for that category.

3. If there is a non-null environment variable LANG, the
   value of LANG is used.

at step 2, the relevant category in this case is LC_CTYPE. So
LC_ALL -> LC_CTYPE -> LANG -> "C".

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v2] clients: Add XKB compose key support

[Ran Benita]

> + /* Look up the appropriate locale, or use "C" as default */
> + locale = getenv("LC_ALL");
> + if (!locale)
> + locale = "C";

Is there a reason why you decided not to use the "full" procedure, i.e.
also try LC_CTYPE and LANG?

> + /* Set up XKB compose table */
> + compose_table = 
> xkb_compose_table_new_from_locale(input->display->xkb_context,
> +   locale,
> +   
> XKB_COMPOSE_COMPILE_NO_FLAGS);
> + if (!compose_table) {
> + fprintf(stderr, "could not create XKB compose table for locale 
> '%s'\n", locale);
> + xkb_state_unref(state);
> + xkb_keymap_unref(keymap);
> + return;
> + }

In my opinion, it would be better to proceed without compose, than to
fail the entire setup. If, for example, the compose files are not
available, then it's OK to just skip it. The alternative is that the
window does not show up at all (I assume).

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libxkbcommon 2/2] README: Add basic build directions

[Ran Benita]

On Thu, Sep 15, 2016 at 02:31:55PM -0700, Bryce Harrington wrote:
> In particular, highlight the use of configure flags to control locating
> X11 keyboard stuff when building for Wayland.
> 
> Of particular note, if the locale root is not specified, then xkbcommon
> will look for them under $prefix (i.e. /usr/local/share/X11/locale).
> But unless the user has specifically installed them there, it is better
> to look in the standard system location, /usr/share/X11/locale.
> 
> Otherwise, xkbcommon will error when it can't find them, e.g.:
> 
>   xkbcommon: ERROR: ~/.XCompose:4:9: failed to expand %L to the locale 
> Compose file
>   xkbcommon: ERROR: ~/.XCompose:4:12: unterminated string literal
> 
> Signed-off-by: Bryce Harrington 

I applied these two as well, thanks!

BTW: The xkb-config-root is usually taken from the xkeyboard-config
pkg-config file, so it's usually not problematic if you have
xkeyboard-config installed during the build.

The x-locale-root is more unfortunate since libX11 does not provide a
pkg-config variable for it. IIRC I tried to add one (and even split the
x-locale stuff to a different repo since the Compose data is useful for
other projects well), but it was ignored... Hopefully distros can split
the libX11 package themselves though.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libxkbcommon] bench: Check for errors opening Compose file

[Ran Benita]

On Thu, Sep 15, 2016 at 02:12:38PM -0700, Bryce Harrington wrote:
> From: Bryce Harrington 
> 
> Otherwise it can segfault e.g. running ./compose inside the bench
> directory.

Applied, thanks!

(I only notice now when replying that you used tabs instead of spaces,
but I'll fix it up myself).
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Re: Re: Questions about disabling key repeat for a keycode or a keysym

[Ran Benita]

On Wed, Apr 20, 2016 at 06:47:22AM +, 박성진 wrote:
> Dear Ran,
> what I did is following. :)
> 
> 1. define a custom keysym in libxkbcommon
>- add a custom keysym into xkbcommon/xkbcommon-keysyms.h file (e.g. 
> XF86VoiceWakeUp)
>- build ks_table.h again to reflect the custom keysym in libxkbcommon
> 2. add a mapping between a keycode and a keysym in xkeyboard-config
>- symbols/inet
>  key  { [XF86VoiceWakeUp ] }

I see there is already

key{  [ XF86Send  ]   };

in the "evdev" map; do you override it, or you're not using "evdev"?

Anyway, to make it not repeat, you can write this:

key  { [XF86VoiceWakeUp ], repeat=False }

> Is it enough information ? :)
> 
> And one more question is... what's the desirable way to define custom keysyms 
> and to do map between
> each keysym to each keycode ?

There is nothing stopping you from modifying xkbcommon-keysyms.h like
you did, but note that xkbcommon-keysyms.h is generated from
/usr/include/X11/keysymdef.h and other files, which are maintained in
the "xproto" package[0]. So, if the keysyms you are adding make general
sense, consider proposing to add them to xproto first. If they're
accepted they will be added in a subsequent xkbcommon release.

[0] https://cgit.freedesktop.org/xorg/proto/xproto/

Alternatively, you can use an "anonymous" keysym, written like
`0x123456`, with an appropriate value, then you can name it in your code
instead of patching xkbcommon.

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Re: Questions about disabling key repeat for a keycode or a keysym

[Ran Benita]

On Tue, Apr 19, 2016 at 09:54:35AM +, 박성진 wrote:
> Dear Ran,
> thank you for your answer. :)
> 
> Plz kindly provide more details about it.
> We have defined some key symbols for built-in keys in mobile handset
> and would like to disable repeat for them.

Can you give an example of such a key symbol you do not want to repeat,
and how and where you defined it (xkb keymap file or elsewhere)?

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Questions about disabling key repeat for a keycode or a keysym

[Ran Benita]

The value returned by `xkb_keymap_key_repeats()` is determined by the
keymap. In xkeyboard-config, it is "calculated" automatically by a
mechanism called "interprets" in the "compat" section, but it can also
be set directly for a given key in the "symbols" section. I can provide
more details if you want.

So to change whether a key repeats at all or not, at least as far as
xkbcommon goes, you need to modify the keymap (i.e. xkeyboard-config).

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon 0.6.0

[Ran Benita]

Here are the NEWS for this release:

libxkbcommon 0.6.0
==

- If the XKB_CONFIG_ROOT environment variable is set, it is used as the XKB
  configuration root instead of the path determined at build time.

- Tests and benchmarks now build correctly on OSX.

- An XKB keymap provides a name for each key it defines.  Traditionally,
  these names are limited to at most 4 characters, and are thus somewhat
  obscure, but might still be useful (xkbcommon lifts the 4 character limit).

  The new functions xkb_keymap_key_get_name() and xkb_keymap_key_by_name()
  can be used to get the name of a key or find a key by name.  Note that
  a key may have aliases.

- Documentation improvements.

- New API:
  xkb_keymap_key_by_name()
  xkb_keymap_key_get_name()


Tarballs:


git tag: xkbcommon-0.6.0

http://xkbcommon.org/download/libxkbcommon-0.6.0.tar.xz
MD5:9746365edb18ac8ff3aeac810885f618  libxkbcommon-0.6.0.tar.xz
SHA1:   b9d9e0a02c9bc439a387dba27ff8115c1f1afb56  libxkbcommon-0.6.0.tar.xz
SHA256: 69235ec3a13194dea9555d7994bc4548b3ee20070e05a135af5372a958149ef0  
libxkbcommon-0.6.0.tar.xz

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] evdev: Log evdev event queue overflows

[Ran Benita]

On Mon, Oct 27, 2014 at 09:26:39AM -0500, Derek Foreman wrote:
 Log a message when the kernel event queue overflows and events are dropped.
 After 10 messages logging stops to avoid flooding the logs if the condition
 is persistent.
 ---
  src/evdev.c | 10 ++
  1 file changed, 10 insertions(+)
 
 diff --git a/src/evdev.c b/src/evdev.c
 index 1b4ce10..c786537 100644
 --- a/src/evdev.c
 +++ b/src/evdev.c
 @@ -912,6 +912,7 @@ evdev_sync_device(struct evdev_device *device)
  static void
  evdev_device_dispatch(void *data)
  {
 + static int overflows = 0;

Does libinput allow static variables? Usually when there's a library
context, it should be possible to use the library from multiple threads,
if they use different contexts.

So maybe this counter should be inside `device` instead of static?

Ran

   struct evdev_device *device = data;
   struct libinput *libinput = device-base.seat-libinput;
   struct input_event ev;
 @@ -924,6 +925,15 @@ evdev_device_dispatch(void *data)
   rc = libevdev_next_event(device-evdev,
LIBEVDEV_READ_FLAG_NORMAL, ev);
   if (rc == LIBEVDEV_READ_STATUS_SYNC) {
 + if (overflows  10) {
 + overflows++;
 + log_info(libinput, Kernel evdev event queue 
 +  overflow for %s\n, device-devname);
 + if (overflows == 10)
 + log_info(libinput, No longer logging 
 +  evdev event queue 
 overflows\n);
 + }
 +
   /* send one more sync event so we handle all
  currently pending events before we sync up
  to the current state */
 -- 
 2.1.1
 
 ___
 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

[ANNOUNCE] libxkbcommon 0.5.0

[Ran Benita]

Here are the NEWS for this release. There's also a new PACKAGING
file[1], for those interested.

[1] https://raw.githubusercontent.com/xkbcommon/libxkbcommon/master/PACKAGING

libxkbcommon 0.5.0 - 2014-10-18
==

- Added support for Compose/dead keys in a new module (included in
  libxkbcommon). See the documentation or the
  xkbcommon/xkbcommon-compose.h header file for more details.

- Improved and reordered some sections of the documentation.

- The doxygen HTML pages were made nicer to read.

- Most tests now run also on non-linux platforms.

- A warning is emitted by default about RMLVO values which are not used
  during keymap compilation, which are most often a user misconfiguration.
  For example, terminate:ctrl_alt_backspace instead of
  terminate:ctrl_alt_bksp.

- Added symbol versioning for libxkbcommon and libxkbcommon-x11.
  Note: binaries compiled against this and future versions will not be
  able to link against the previous versions of the library.

- Removed several compatablity symbols from the binary (the API isn't
  affected). This affects binaries which

  1. Were compiled against a pre-stable (0.2.0) version of libxkbcommon, and
  2. Are linked against the this or later version of libxkbcommon.

  Such a scenario is likely to fail already.

- If Xvfb is not available, the x11comp test is now correctly skipped
  instead of hanging.

- Benchmarks were moved to a separate bench/ directory.

- Build fixes from OpenBSD.

- Fixed a bug where key type entries such as map[None] = Level2; were
  ignored.

- New API:
  XKB_COMPOSE_*
  xkb_compose_*

Tarballs:


git tag: xkbcommon-0.5.0

http://xkbcommon.org/download/libxkbcommon-0.5.0.tar.xz
MD5:  2e1faeafcc609c30af3a561a91e84158  libxkbcommon-0.5.0.tar.xz
SHA1: 7127993bfb69e13cdff25fb8b3c8f26ce6be5bfa libxkbcommon-0.5.0.tar.xz

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libxkbcommon 1/4] compose: add xkbcommon-compose - API

[Ran Benita]

On Mon, Sep 15, 2014 at 08:41:37AM +0200, David Herrmann wrote:
 Hi

Hi David

 On Sun, Sep 14, 2014 at 11:05 PM, Ran Benita ran...@gmail.com wrote:
[snip]
  +/**
  + * @page compose-cancellation Cancellation Behavior
  + * @parblock
  + *
  + * What should happen when a sequence is cancelled?  For example, consider
  + * there are only the above sequences, and the input kesysms are
  + * \dead_acute\ \b\.  There are a few approaches:
  + *
  + * 1. Swallow the cancelling keysym; that is, no keysym is produced.
  + *This is the approach taken by libX11.
  + * 2. Let the cancelling keysym through; that is, \b\ is produced.
  + * 3. Replay the entire sequence; that is, \dead_acute\ \b\ is 
  produced.
  + *This is the approach taken by Microsoft Windows (approximately;
  + *instead of \dead_acute\, the underlying key is used.  This is
  + *difficult to simulate with XKB keymaps).
  + *
  + * You can program whichever approach best fits users' expectations.
 
 Hm, implementing 3) is a pain as we have to track the keysyms
 separately. Your compose-API does not provide a way to retrieve the
 parsed/failed sequence. 

I think alternative 3 is the nicest really, so I want to make it
possible, without too much work if possible.

Tracking the sequence is possible - I've added a return value to
xkb_compose_state_feed() for this purpose. It can be done with e.g. a
wrapper over xkb_compose_state_feed(), something like:

/* sequence, sequence_len is a persisting array of keysyms. */
enum xkb_compose_feed_result result;
enum xkb_compose_status status;

result = xkb_compose_state_feed(compose_state, keysym);
if (result == XKB_COMPOSE_FEED_IGNORED)
return;

status = xkb_compose_state_get_status(compose_state);
if ((status == XKB_COMPOSE_COMPOSING || status == XKB_COMPOSE_COMPOSED) 
sequence_len  ARRAY_SIZE(sequence))
sequence[sequence_len++] = keysym;

/* probably want to do something with the sequence if COMPOSED or
   CANCELLED. But in these cases the sequence needs to be reset
   (Can be a wrapper over xkb_state_compose_reset()). */

I considered adding a function for getting the current sequence, i.e.
doing the above internally. But that's problematic because when a
sequence is cancelled for example, I should reset the sequence, but
that's exactly when the user wants the sequence.

Also, one reasonable way to do #3 is to replay events for the cancelled
sequence. But then you need to remember other stuff, like the keycodes,
timestamps, etc., so the user needs to do the tracking himself anyway.

 But given that we have no dead-key =
 normal-key conversion right now, it's probably fine. If we want it, we
 can add an API for both later on (assuming a trivial keysym conversion
 from dead_key = normal is possible).

Yes, maybe we can add such a function, once we have more experience.
Another option, which relies entirely on convention, is to feed the
dead key twice, and see what comes out:

$ grep -P '^dead_(.*) dead_\1' /usr/share/X11/locale/en_US.UTF-8/Compose

dead_tilde dead_tilde   : ~  asciitilde # TILDE
dead_acute dead_acute   : ´  acute # ACUTE ACCENT
dead_grave dead_grave   : `  grave # GRAVE ACCENT
dead_circumflex dead_circumflex : ^  asciicircum # CIRCUMFLEX 
ACCENT
dead_abovering dead_abovering   : °  degree # DEGREE SIGN
dead_macron dead_macron : ¯  macron # MACRON
dead_breve dead_breve   : ˘  breve # BREVE
dead_abovedot dead_abovedot : ˙  abovedot # DOT ABOVE
dead_diaeresis dead_diaeresis   : ¨  diaeresis # DIAERESIS
dead_doubleacute dead_doubleacute   : ˝  U2dd # DOUBLE ACUTE ACCENT
dead_caron dead_caron   : ˇ  caron # CARON
dead_cedilla dead_cedilla   : ¸  cedilla # CEDILLA
dead_ogonek dead_ogonek : ˛  ogonek # OGONEK
dead_iota dead_iota : ͺ  U37a # GREEK YPOGEGRAMMENI
dead_belowdot dead_belowdot : ̣   U0323 # COMBINING DOT BELOW
dead_belowcomma dead_belowcomma : ,  comma # COMMA
dead_currency dead_currency : ¤  currency # CURRENCY SIGN
dead_greek dead_greek   : µ  U00B5 # MICRO SIGN
dead_hook dead_hook : ̉   U0309 # COMBINING HOOK ABOVE
dead_horn dead_horn : ̛   U031B # COMBINING HORN
dead_stroke dead_stroke : /  slash # SOLIDUS

Probably not a good idea..

 I also don't understand why dead-keys are related to keymaps? I mean,
 yeah, the nodeadkey variant is part of the keymap, but the keymap
 never defines behavior of dead-keys. We could simply provide a lookup
 table that converts XKB_KEY_dead_xyz to XKB_KEY_xyz, right?

Right, this is what I meant with This is difficult to simulate with XKB
keymaps. But I need to research this a bit more..

Btw, when I wrote this is what Windows does it was from vague memory and
some internet searching

Re: [PATCH libxkbcommon 2/4] compose: add xkbcommon-compose - implementation

[Ran Benita]

On Mon, Sep 15, 2014 at 08:21:34AM +0200, David Herrmann wrote:
 Hi
 
 On Sun, Sep 14, 2014 at 11:05 PM, Ran Benita ran...@gmail.com wrote:
  Signed-off-by: Ran Benita ran...@gmail.com
  ---
 
 [snip]
 
  diff --git a/src/compose/state.c b/src/compose/state.c
  new file mode 100644
  index 000..06e4ce5
  --- /dev/null
  +++ b/src/compose/state.c
  @@ -0,0 +1,196 @@
  +/*
  + * Copyright © 2013 Ran Benita ran...@gmail.com
  + *
  + * Permission is hereby granted, free of charge, to any person obtaining a
  + * copy of this software and associated documentation files (the 
  Software),
  + * to deal in the Software without restriction, including without 
  limitation
  + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
  + * and/or sell copies of the Software, and to permit persons to whom the
  + * Software is furnished to do so, subject to the following conditions:
  + *
  + * The above copyright notice and this permission notice (including the 
  next
  + * paragraph) shall be included in all copies or substantial portions of 
  the
  + * Software.
  + *
  + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS 
  OR
  + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
  + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
  + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
  OTHER
  + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
  + * DEALINGS IN THE SOFTWARE.
  + */
  +
  +#include table.h
  +#include utils.h
  +#include keysym.h
  +
  +struct xkb_compose_state {
  +int refcnt;
  +enum xkb_compose_state_flags flags;
  +struct xkb_compose_table *table;
  +
  +/*
  + * Offsets into xkb_compose_table::nodes.
  + *
  + * They maintain the current and previous position in the trie; see
  + * xkb_compose_state_feed().
  + *
  + * This is also sufficient for inferring the current status; see
  + * xkb_compose_state_get_status().
  + */
  +uint32_t prev_context;
  +uint32_t context;
  +};
  +
  +XKB_EXPORT struct xkb_compose_state *
  +xkb_compose_state_new(struct xkb_compose_table *table,
  +  enum xkb_compose_state_flags flags)
  +{
  +struct xkb_compose_state *state;
  +
  +state = calloc(1, sizeof(*state));
  +if (!state)
  +return NULL;
  +
  +state-refcnt = 1;
  +state-table = xkb_compose_table_ref(table);
  +
  +state-flags = flags;
  +state-prev_context = 0;
  +state-context = 0;
  +
  +return state;
  +}
  +
  +XKB_EXPORT struct xkb_compose_state *
  +xkb_compose_state_ref(struct xkb_compose_state *state)
  +{
  +state-refcnt++;
  +return state;
  +}
  +
  +XKB_EXPORT void
  +xkb_compose_state_unref(struct xkb_compose_state *state)
  +{
  +if (!state || --state-refcnt  0)
  +return;
  +
  +xkb_compose_table_unref(state-table);
  +free(state);
  +}
  +
  +XKB_EXPORT struct xkb_compose_table *
  +xkb_compose_state_get_compose_table(struct xkb_compose_state *state)
  +{
  +return state-table;
  +}
  +
  +XKB_EXPORT enum xkb_compose_feed_result
  +xkb_compose_state_feed(struct xkb_compose_state *state, xkb_keysym_t 
  keysym)
  +{
  +uint32_t context;
  +const struct compose_node *node;
  +
  +/*
  + * Modifiers do not affect the sequence directly.  In particular,
  + * they do not cancel a sequence; otherwise it'd be impossible to
  + * have a sequence like dead_acuteA (needs Shift in the middle).
  + *
  + * The following test is not really accurate - in order to test if
  + * a key is modifier key, we really need the keymap, but we don't
  + * have it here.  However, this is (approximately) what libX11 does
  + * as well.
  + */
  +if (xkb_keysym_is_modifier(keysym))
  +return XKB_COMPOSE_FEED_IGNORED;
 
 Why don't we require a keymap in xkb_compose_state_new()? Should be
 easy to do and we can then track modifiers reliably.
 Ok, a keysym which is a modifier in one keymap should never be a
 normal key in another.. unlike keycodes. But I don't see why we need
 to rely on that when we can just take a keymap.

I prefer not adding a dependency on a keymap just for this one little
thing. That would preclude people who don't use xkbcommon keymaps from
using xkbcommon-compose (not likely, but maybe), and complicate the API
slightly. For not much gain..

Also, that's what the de facto specification here (Xlib) says, so it's not
a bug, it's a feature :)

 Otherwise, looks good (I didn't read through the parser, though).

Thanks again!
Ran

 Thanks
 David
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libxkbcommon 2/4] compose: add xkbcommon-compose - implementation

[Ran Benita]

Signed-off-by: Ran Benita ran...@gmail.com
---
 Makefile.am  |   9 +
 configure.ac |   9 +
 src/compose/parser.c | 625 +++
 src/compose/parser.h |  36 +++
 src/compose/paths.c  | 204 +
 src/compose/paths.h  |  42 
 src/compose/state.c  | 196 
 src/compose/table.c  | 219 ++
 src/compose/table.h  | 122 ++
 src/keysym.c |   3 +-
 xkbcommon.map|  14 ++
 11 files changed, 1478 insertions(+), 1 deletion(-)
 create mode 100644 src/compose/parser.c
 create mode 100644 src/compose/parser.h
 create mode 100644 src/compose/paths.c
 create mode 100644 src/compose/paths.h
 create mode 100644 src/compose/state.c
 create mode 100644 src/compose/table.c
 create mode 100644 src/compose/table.h

diff --git a/Makefile.am b/Makefile.am
index 0b315d0..c4ab787 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -14,6 +14,7 @@ EXTRA_DIST = \
 
 AM_CPPFLAGS = \
-DDFLT_XKB_CONFIG_ROOT='$(XKBCONFIGROOT)' \
+   -DXLOCALEDIR='$(XLOCALEDIR)' \
-I$(top_srcdir)/src \
-I$(top_srcdir)/src/xkbcomp \
-I$(top_builddir)/src/xkbcomp \
@@ -32,11 +33,19 @@ xkbcommonincludedir = $(includedir)/xkbcommon
 xkbcommoninclude_HEADERS = \
xkbcommon/xkbcommon.h \
xkbcommon/xkbcommon-compat.h \
+   xkbcommon/xkbcommon-compose.h \
xkbcommon/xkbcommon-keysyms.h \
xkbcommon/xkbcommon-names.h
 
 lib_LTLIBRARIES = libxkbcommon.la
 libxkbcommon_la_SOURCES = \
+   src/compose/parser.c \
+   src/compose/parser.h \
+   src/compose/paths.c \
+   src/compose/paths.h \
+   src/compose/state.c \
+   src/compose/table.c \
+   src/compose/table.h \
src/xkbcomp/action.c \
src/xkbcomp/action.h \
src/xkbcomp/ast.h \
diff --git a/configure.ac b/configure.ac
index 791e158..7449954 100644
--- a/configure.ac
+++ b/configure.ac
@@ -107,6 +107,14 @@ AC_ARG_WITH([xkb_config_root],
 [XKBCONFIGROOT=$xkb_base])
 AC_SUBST([XKBCONFIGROOT])
 
+# Define a configuration option for the X locale directory for compose
+AC_ARG_WITH([x_locale_root],
+[AS_HELP_STRING([--with-x-locale-root=path],
+[Set X locale root (default: $datadir/X11/locale)])],
+[XLOCALEDIR=$withval],
+[XLOCALEDIR=$datadir/X11/locale])
+AC_SUBST([XLOCALEDIR])
+
 AC_ARG_WITH([default_rules],
 [AS_HELP_STRING([--with-default-rules=path],
 [Default XKB ruleset (default: evdev)])],
@@ -189,4 +197,5 @@ AC_MSG_RESULT([
 includedir:  ${includedir}
 lib dir: ${libdir}
 XKB config root: ${XKBCONFIGROOT}
+X11 locale root: ${XLOCALEDIR}
 ])
diff --git a/src/compose/parser.c b/src/compose/parser.c
new file mode 100644
index 000..1aff203
--- /dev/null
+++ b/src/compose/parser.c
@@ -0,0 +1,625 @@
+/*
+ * Copyright © 2013 Ran Benita ran...@gmail.com
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include errno.h
+
+#include utils.h
+#include scanner-utils.h
+#include table.h
+#include paths.h
+#include utf8.h
+#include parser.h
+
+#define MAX_LHS_LEN 10
+#define MAX_INCLUDE_DEPTH 5
+
+#define KEYSYM_FROM_NAME_CACHE_SIZE 8
+
+/*
+ * xkb_keysym_from_name() is fairly slow, because for internal reasons
+ * it must use strcasecmp().
+ * A small cache reduces about 20% from the compilation time of
+ * en_US.UTF-8/Compose.
+ */
+struct keysym_from_name_cache {
+struct {
+char name[64];
+xkb_keysym_t keysym;
+} cache[KEYSYM_FROM_NAME_CACHE_SIZE];
+unsigned next;
+};
+
+static xkb_keysym_t
+cached_keysym_from_name(struct keysym_from_name_cache *cache,
+const char *name, size_t len)
+{
+xkb_keysym_t keysym;
+
+if (len = sizeof(cache-cache[0].name))
+return XKB_KEY_NoSymbol;
+
+for (unsigned i = 0; i  KEYSYM_FROM_NAME_CACHE_SIZE; i

[PATCH libxkbcommon 1/4] compose: add xkbcommon-compose - API

[Ran Benita]

xkbcommon-compose is a Compose implementation for xkbcommon. It mostly
behaves like libX11's Compose, but the support is somewhat low-level and
is not transparent like in libX11. The user must add some supporting code
in order to utilize it.

The intended audience are users who use xkbcommon but not a full-blown
input method. With this they can add Compose support in a straightforward
manner, so they have a fairly complete keyboard input for Latin-like
languages at least.

See the header documentation for details.

Signed-off-by: Ran Benita ran...@gmail.com
---
 xkbcommon/xkbcommon-compose.h | 457 ++
 1 file changed, 457 insertions(+)
 create mode 100644 xkbcommon/xkbcommon-compose.h

diff --git a/xkbcommon/xkbcommon-compose.h b/xkbcommon/xkbcommon-compose.h
new file mode 100644
index 000..ed35250
--- /dev/null
+++ b/xkbcommon/xkbcommon-compose.h
@@ -0,0 +1,457 @@
+/*
+ * Copyright © 2013 Ran Benita
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef _XKBCOMMON_COMPOSE_H
+#define _XKBCOMMON_COMPOSE_H
+
+#include xkbcommon/xkbcommon.h
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+/**
+ * @file
+ * libxkbcommon Compose API - support for Compose and dead-keys.
+ */
+
+/**
+ * @defgroup compose Compose and dead-keys support
+ * Support for Compose and dead-keys.
+ * @since TBD
+ *
+ * @{
+ */
+
+/**
+ * @page compose-overview Overview
+ * @parblock
+ *
+ * Compose and dead-keys are a common feature of many keyboard input
+ * systems.  They extend the range of the keysysm that can be produced
+ * directly from a keyboard by using a sequence of key strokes, instead
+ * of just one.
+ *
+ * Here are some example sequences, in the libX11 Compose file format:
+ *
+ * dead_acute a : á   aacute # LATIN SMALL LETTER A WITH 
ACUTE
+ * Multi_key A T  : @   at # COMMERCIAL AT
+ *
+ * When the user presses a key which produces the \dead_acute keysym,
+ * nothing initially happens (thus the key is dubbed a dead-key).  But
+ * when the user enters a, á is composed, in place of a.  If
+ * instead the user had entered a keysym which does not follow
+ * \dead_acute\ in any compose sequence, the sequence is said to be
+ * cancelled.
+ *
+ * Compose files define many such sequences.  For a description of the
+ * common file format for Compose files, see the Compose(5) man page.
+ *
+ * A successfuly-composed sequence has two results: a keysym and a UTF-8
+ * string.  At least one of the two is defined for each sequence.  If only
+ * a keysym is given, the keysym's string representation is used for the
+ * result string (using xkb_keysym_to_utf8()).
+ *
+ * This library provides low-level support for Compose file parsing and
+ * processing.  Higher-level APIs (such as libX11's Xutf8LookupString(3))
+ * may be built upon it, or it can be used directly.
+ *
+ * @endparblock
+ */
+
+/**
+ * @page compose-conflicting Conflicting Sequences
+ * @parblock
+ *
+ * To avoid ambiguity, a sequence is not allowed to be a prefix of another.
+ * In such a case, the conflict is resolved thus:
+ *
+ * 1. A longer sequence overrides a shorter one.
+ * 2. An equal sequence overrides an existing one.
+ * 3. A shorter sequence does not override a longer one.
+ *
+ * Sequences of length 1 are allowed, although they are not common.
+ *
+ * @endparblock
+ */
+
+/**
+ * @page compose-cancellation Cancellation Behavior
+ * @parblock
+ *
+ * What should happen when a sequence is cancelled?  For example, consider
+ * there are only the above sequences, and the input kesysms are
+ * \dead_acute\ \b\.  There are a few approaches:
+ *
+ * 1. Swallow the cancelling keysym; that is, no keysym is produced.
+ *This is the approach taken by libX11.
+ * 2. Let the cancelling keysym through; that is, \b\ is produced.
+ * 3. Replay the entire sequence; that is, \dead_acute\ \b\ is produced.
+ *This is the approach taken

Compose and dead-keys support in libxkbcommon

[Ran Benita]

These patches add support for compose sequences/dead keys to
libxkbcommon, in a small mostly-independent module, xkbcommon-compose.
A while ago we decided this is a worthwhile addition, particulary for
applications which use libxkbcommon without an input method.

I'd appreciate any comments on the API. The implementation is mostly
included for reference if someone's interested.

You can also find the patches here (with some boring preperatory
commits):
https://github.com/xkbcommon/libxkbcommon/tree/compose

Thanks,
Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libxkbcommon 4/4] test/interactive-evdev: add compose support

[Ran Benita]

To try, do e.g.:
sudo ./test/interactive-evdev -l us -v intl -o compose:ralt -d

Signed-off-by: Ran Benita ran...@gmail.com
---
 test/common.c| 43 +-
 test/interactive-evdev.c | 68 +---
 test/interactive-x11.c   |  2 +-
 test/test.h  |  5 +++-
 4 files changed, 94 insertions(+), 24 deletions(-)

diff --git a/test/common.c b/test/common.c
index e6cd1c3..0bacba0 100644
--- a/test/common.c
+++ b/test/common.c
@@ -347,14 +347,18 @@ test_compile_rules(struct xkb_context *context, const 
char *rules,
 }
 
 void
-test_print_keycode_state(struct xkb_state *state, xkb_keycode_t keycode)
+test_print_keycode_state(struct xkb_state *state,
+ struct xkb_compose_state *compose_state,
+ xkb_keycode_t keycode)
 {
 struct xkb_keymap *keymap;
 
+xkb_keysym_t sym;
 const xkb_keysym_t *syms;
 int nsyms;
 char s[16];
 xkb_layout_index_t layout;
+enum xkb_compose_status status;
 
 keymap = xkb_state_get_keymap(state);
 
@@ -363,21 +367,34 @@ test_print_keycode_state(struct xkb_state *state, 
xkb_keycode_t keycode)
 if (nsyms = 0)
 return;
 
-if (nsyms == 1) {
-xkb_keysym_t sym = xkb_state_key_get_one_sym(state, keycode);
-xkb_keysym_get_name(sym, s, sizeof(s));
-printf(keysym [ %-*s ] , (int) sizeof(s), s);
+status = XKB_COMPOSE_NOTHING;
+if (compose_state)
+status = xkb_compose_state_get_status(compose_state);
+
+if (status == XKB_COMPOSE_COMPOSING || status == XKB_COMPOSE_CANCELLED)
+return;
+
+if (status == XKB_COMPOSE_COMPOSED) {
+sym = xkb_compose_state_get_one_sym(compose_state);
+syms = sym;
+nsyms = 1;
 }
-else {
-printf(keysyms [ );
-for (int i = 0; i  nsyms; i++) {
-xkb_keysym_get_name(syms[i], s, sizeof(s));
-printf(%-*s , (int) sizeof(s), s);
-}
-printf(] );
+else if (nsyms == 1) {
+sym = xkb_state_key_get_one_sym(state, keycode);
+syms = sym;
+}
+
+printf(keysyms [ );
+for (int i = 0; i  nsyms; i++) {
+xkb_keysym_get_name(syms[i], s, sizeof(s));
+printf(%-*s , (int) sizeof(s), s);
 }
+printf(] );
 
-xkb_state_key_get_utf8(state, keycode, s, sizeof(s));
+if (status == XKB_COMPOSE_COMPOSED)
+xkb_compose_state_get_utf8(compose_state, s, sizeof(s));
+else
+xkb_state_key_get_utf8(state, keycode, s, sizeof(s));
 printf(unicode [ %s ] , s);
 
 layout = xkb_state_key_get_layout(state, keycode);
diff --git a/test/interactive-evdev.c b/test/interactive-evdev.c
index c3c4965..04a347f 100644
--- a/test/interactive-evdev.c
+++ b/test/interactive-evdev.c
@@ -40,12 +40,14 @@ struct keyboard {
 char *path;
 int fd;
 struct xkb_state *state;
+struct xkb_compose_state *compose_state;
 struct keyboard *next;
 };
 
 static bool terminate;
 static int evdev_offset = 8;
 static bool report_state_changes;
+static bool with_compose;
 
 #define NLONGS(n) (((n) + LONG_BIT - 1) / LONG_BIT)
 
@@ -85,12 +87,13 @@ is_keyboard(int fd)
 
 static int
 keyboard_new(struct dirent *ent, struct xkb_keymap *keymap,
- struct keyboard **out)
+ struct xkb_compose_table *compose_table, struct keyboard **out)
 {
 int ret;
 char *path;
 int fd;
 struct xkb_state *state;
+struct xkb_compose_state *compose_state = NULL;
 struct keyboard *kbd;
 
 ret = asprintf(path, /dev/input/%s, ent-d_name);
@@ -116,18 +119,31 @@ keyboard_new(struct dirent *ent, struct xkb_keymap 
*keymap,
 goto err_fd;
 }
 
+if (with_compose) {
+compose_state = xkb_compose_state_new(compose_table,
+  XKB_COMPOSE_STATE_NO_FLAGS);
+if (!compose_state) {
+fprintf(stderr, Couldn't create compose state for %s\n, path);
+ret = -EFAULT;
+goto err_state;
+}
+}
+
 kbd = calloc(1, sizeof(*kbd));
 if (!kbd) {
 ret = -ENOMEM;
-goto err_state;
+goto err_compose_state;
 }
 
 kbd-path = path;
 kbd-fd = fd;
 kbd-state = state;
+kbd-compose_state = compose_state;
 *out = kbd;
 return 0;
 
+err_compose_state:
+xkb_compose_state_unref(compose_state);
 err_state:
 xkb_state_unref(state);
 err_fd:
@@ -146,6 +162,7 @@ keyboard_free(struct keyboard *kbd)
 close(kbd-fd);
 free(kbd-path);
 xkb_state_unref(kbd-state);
+xkb_compose_state_unref(kbd-compose_state);
 free(kbd);
 }
 
@@ -156,7 +173,8 @@ filter_device_name(const struct dirent *ent)
 }
 
 static struct keyboard *
-get_keyboards(struct xkb_keymap *keymap)
+get_keyboards(struct xkb_keymap *keymap,
+  struct xkb_compose_table *compose_table)
 {
 int ret, i, nents;
 struct dirent **ents;
@@ -169,7 +187,7 @@ get_keyboards(struct

Re: [PATCH] build: use symbol versioning

[Ran Benita]

On Tue, Sep 09, 2014 at 07:08:46PM +0200, Jan Engelhardt wrote:
 Symbol versions provide a means by which ELF utilities can determine
 whether a program is incompatible with a too-old library version so
 that package management tools can autodetect version-based
 dependencies and suggest upgrade paths.

Thanks, that's nice, applied. I don't think we support any platforms
which don't support simple version scripts, but if there are, we can
make this conditional.

Note that the patch had a little mixup with the version scripts file
names (the xkbcommon.map had the -x11 symbols and vice versa), so I
fixed that.

I also made a follow up commit which removes some deprecated symbols.
Now is a good time to do that.
https://github.com/xkbcommon/libxkbcommon/commit/f03dcf9fb6c35ab622cfdfacb8eb849c69be609d

Ran

 
 Signed-off-by: Jan Engelhardt jeng...@inai.de
 ---
 The name chosen for symbols (V_0.4.3) does not play a role as long as it is
 unique within a particular .so file. Therefore, there is also no requirement
 to use fancy long names like LIBXKBCOMMON_0.4.3.
 
  Makefile.am   |  2 ++
  xkbcommon-x11.map | 73 
 +++
  xkbcommon.map |  9 +++
  3 files changed, 84 insertions(+)
  create mode 100644 xkbcommon-x11.map
  create mode 100644 xkbcommon.map
 
 diff --git a/Makefile.am b/Makefile.am
 index 6ad2cd6..ccba897 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -84,6 +84,7 @@ libxkbcommon_la_SOURCES = \
   src/utf8.h \
   src/utils.c \
   src/utils.h
 +libxkbcommon_la_LDFLAGS = -Wl,--version-script=${srcdir}/xkbcommon-x11.map
  
  if ENABLE_X11
  pkgconfig_DATA += xkbcommon-x11.pc
 @@ -97,6 +98,7 @@ lib_LTLIBRARIES += libxkbcommon-x11.la
  libxkbcommon_x11_la_CFLAGS = $(AM_CFLAGS) $(XCB_XKB_CFLAGS)
  libxkbcommon_x11_la_CPPFLAGS = $(AM_CPPFLAGS) -I$(top_srcdir)/src/x11
  libxkbcommon_x11_la_LIBADD = libxkbcommon.la $(XCB_XKB_LIBS)
 +libxkbcommon_x11_la_LDFLAGS = -Wl,--version-script=${srcdir}/xkbcommon.map
  
  libxkbcommon_x11_la_SOURCES = \
   src/x11/keymap.c \
 diff --git a/xkbcommon-x11.map b/xkbcommon-x11.map
 new file mode 100644
 index 000..919c0dc
 --- /dev/null
 +++ b/xkbcommon-x11.map
 @@ -0,0 +1,73 @@
 +V_0.4.3 {
 +global:
 + xkb_keysym_get_name;
 + xkb_keysym_from_name;
 + xkb_keysym_to_utf8;
 + xkb_keysym_to_utf32;
 + xkb_context_new;
 + xkb_context_ref;
 + xkb_context_unref;
 + xkb_context_set_user_data;
 + xkb_context_get_user_data;
 + xkb_context_include_path_append;
 + xkb_context_include_path_append_default;
 + xkb_context_include_path_reset_defaults;
 + xkb_context_include_path_clear;
 + xkb_context_num_include_paths;
 + xkb_context_include_path_get;
 + xkb_context_set_log_level;
 + xkb_context_get_log_level;
 + xkb_context_set_log_verbosity;
 + xkb_context_get_log_verbosity;
 + xkb_context_set_log_fn;
 + xkb_keymap_new_from_names;
 + xkb_keymap_new_from_file;
 + xkb_keymap_new_from_string;
 + xkb_keymap_new_from_buffer;
 + xkb_keymap_ref;
 + xkb_keymap_unref;
 + xkb_keymap_get_as_string;
 + xkb_keymap_min_keycode;
 + xkb_keymap_max_keycode;
 + xkb_keymap_key_for_each;
 + xkb_keymap_num_mods;
 + xkb_keymap_mod_get_name;
 + xkb_keymap_mod_get_index;
 + xkb_keymap_num_layouts;
 + xkb_keymap_layout_get_name;
 + xkb_keymap_layout_get_index;
 + xkb_keymap_num_layouts_for_key;
 + xkb_keymap_num_levels_for_key;
 + xkb_keymap_key_get_syms_by_level;
 + xkb_keymap_num_leds;
 + xkb_keymap_led_get_name;
 + xkb_keymap_led_get_index;
 + xkb_keymap_key_repeats;
 + xkb_state_new;
 + xkb_state_ref;
 + xkb_state_unref;
 + xkb_state_get_keymap;
 + xkb_state_update_key;
 + xkb_state_update_mask;
 + xkb_state_key_get_syms;
 + xkb_state_key_get_utf8;
 + xkb_state_key_get_utf32;
 + xkb_state_key_get_one_sym;
 + xkb_state_key_get_layout;
 + xkb_state_key_get_level;
 + xkb_state_serialize_mods;
 + xkb_state_serialize_layout;
 + xkb_state_mod_name_is_active;
 + xkb_state_mod_names_are_active;
 + xkb_state_mod_index_is_active;
 + xkb_state_mod_indices_are_active;
 + xkb_state_mod_index_is_consumed;
 + xkb_state_mod_mask_remove_consumed;
 + xkb_state_key_get_consumed_mods;
 + xkb_state_layout_name_is_active;
 + xkb_state_layout_index_is_active;
 + xkb_state_led_name_is_active;
 + xkb_state_led_index_is_active;
 +local:
 + *;
 +};
 diff --git a/xkbcommon.map b/xkbcommon.map
 new file mode 100644
 index 000..c1a3240
 --- /dev/null
 +++ b/xkbcommon.map
 @@ -0,0 +1,9 @@
 +V_0.4.3 {
 +global:
 + xkb_x11_setup_xkb_extension;
 + xkb_x11_get_core_keyboard_device_id;
 + xkb_x11_keymap_new_from_device;
 + xkb_x11_state_new_from_device;
 +local:
 + *;
 +};
 -- 
 2.0.0
 
___
wayland-devel mailing list

[ANNOUNCE] libxkbcommon 0.4.3

[Ran Benita]

A new release of libxkbcommon, containing mostly bug-fixes.

libxkbcommon 0.4.3 - 2014-08-19
==

- Fixed a bug which caused xkb_x11_keymap_new_from_device() to misrepresent
  modifiers for some keymaps.

  https://github.com/xkbcommon/libxkbcommon/issues/9

- Fixed a bug which caused xkb_x11_keymap_new_from_device() to ignore XKB
  PrivateAction's.

- Modifiers are now always fully resolved after xkb_state_update_mask().
  Previously the given state components were used as-is, without
  considering virtual modifier mappings.
  Note: this only affects non-standard uses of xkb_state_update_mask().

- Added a test for xkbcommon-x11, x11comp. The test uses the system's
  Xvfb server and xkbcomp. If they do not exist or fail, the test is
  skipped.

- Fixed memory leaks after parse errors in the XKB yacc parser.
  The fix required changes which are currently incompatible with byacc.

  https://github.com/xkbcommon/libxkbcommon/issues/8


Tarballs:


git tag: xkbcommon-0.4.3

http://xkbcommon.org/download/libxkbcommon-0.4.3.tar.xz
MD5:  26c57ff21438ed45de2a4ca609177db9  libxkbcommon-0.4.3.tar.xz
SHA1: 2251adc7425c816ec7af4f1c3776a619a53293b6 libxkbcommon-0.4.3.tar.xz

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 1/2] Replace deprecated xkbcommon symbols with current names

[Ran Benita]

These symbols (xkb_map_* and others) were replaced in xkbcommon with more
consistent names. See the header xkbcommon/xkbcommon-compat.h for how
the old names map to the new.

The new names have been available since the first stable xkbcommon
release (0.2.0).

Signed-off-by: Ran Benita ran...@gmail.com
---
 clients/weston-simple-im.c | 22 
 clients/window.c   | 24 -
 src/compositor-wayland.c   | 10 +++
 src/compositor-x11.c   |  4 +--
 src/input.c| 66 --
 src/screen-share.c | 10 +++
 6 files changed, 70 insertions(+), 66 deletions(-)

diff --git a/clients/weston-simple-im.c b/clients/weston-simple-im.c
index ded6a04..787782f 100644
--- a/clients/weston-simple-im.c
+++ b/clients/weston-simple-im.c
@@ -187,10 +187,10 @@ input_method_keyboard_keymap(void *data,
}
 
keyboard-keymap =
-   xkb_map_new_from_string(keyboard-xkb_context,
-   map_str,
-   XKB_KEYMAP_FORMAT_TEXT_V1,
-   0);
+   xkb_keymap_new_from_string(keyboard-xkb_context,
+  map_str,
+  XKB_KEYMAP_FORMAT_TEXT_V1,
+  0);
 
munmap(map_str, size);
close(fd);
@@ -203,16 +203,16 @@ input_method_keyboard_keymap(void *data,
keyboard-state = xkb_state_new(keyboard-keymap);
if (!keyboard-state) {
fprintf(stderr, failed to create XKB state\n);
-   xkb_map_unref(keyboard-keymap);
+   xkb_keymap_unref(keyboard-keymap);
return;
}
 
keyboard-control_mask =
-   1  xkb_map_mod_get_index(keyboard-keymap, Control);
+   1  xkb_keymap_mod_get_index(keyboard-keymap, Control);
keyboard-alt_mask =
-   1  xkb_map_mod_get_index(keyboard-keymap, Mod1);
+   1  xkb_keymap_mod_get_index(keyboard-keymap, Mod1);
keyboard-shift_mask =
-   1  xkb_map_mod_get_index(keyboard-keymap, Shift);
+   1  xkb_keymap_mod_get_index(keyboard-keymap, Shift);
 }
 
 static void
@@ -234,7 +234,7 @@ input_method_keyboard_key(void *data,
return;
 
code = key + 8;
-   num_syms = xkb_key_get_syms(keyboard-state, code, syms);
+   num_syms = xkb_state_key_get_syms(keyboard-state, code, syms);
 
sym = XKB_KEY_NoSymbol;
if (num_syms == 1)
@@ -261,8 +261,8 @@ input_method_keyboard_modifiers(void *data,
xkb_state_update_mask(keyboard-state, mods_depressed,
  mods_latched, mods_locked, 0, 0, group);
mask = xkb_state_serialize_mods(keyboard-state,
-   XKB_STATE_DEPRESSED |
-   XKB_STATE_LATCHED);
+   XKB_STATE_MODS_DEPRESSED |
+   XKB_STATE_MODS_LATCHED);
 
keyboard-modifiers = 0;
if (mask  keyboard-control_mask)
diff --git a/clients/window.c b/clients/window.c
index a8bc260..90f45d3 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -2749,10 +2749,10 @@ keyboard_handle_keymap(void *data, struct wl_keyboard 
*keyboard,
return;
}
 
-   keymap = xkb_map_new_from_string(input-display-xkb_context,
-map_str,
-XKB_KEYMAP_FORMAT_TEXT_V1,
-0);
+   keymap = xkb_keymap_new_from_string(input-display-xkb_context,
+   map_str,
+   XKB_KEYMAP_FORMAT_TEXT_V1,
+   0);
munmap(map_str, size);
close(fd);
 
@@ -2764,7 +2764,7 @@ keyboard_handle_keymap(void *data, struct wl_keyboard 
*keyboard,
state = xkb_state_new(keymap);
if (!state) {
fprintf(stderr, failed to create XKB state\n);
-   xkb_map_unref(keymap);
+   xkb_keymap_unref(keymap);
return;
}
 
@@ -2774,11 +2774,11 @@ keyboard_handle_keymap(void *data, struct wl_keyboard 
*keyboard,
input-xkb.state = state;
 
input-xkb.control_mask =
-   1  xkb_map_mod_get_index(input-xkb.keymap, Control);
+   1  xkb_keymap_mod_get_index(input-xkb.keymap, Control);
input-xkb.alt_mask =
-   1  xkb_map_mod_get_index(input-xkb.keymap, Mod1);
+   1  xkb_keymap_mod_get_index(input-xkb.keymap, Mod1);
input-xkb.shift_mask =
-   1  xkb_map_mod_get_index(input-xkb.keymap, Shift);
+   1  xkb_keymap_mod_get_index(input-xkb.keymap, Shift);
 }
 
 static void
@@ -2834,7 +2834,7 @@ keyboard_handle_key(void *data

[PATCH weston 2/2] Don't protect xkb_*_unref from NULL

[Ran Benita]

Since xkbcommon-0.3.0, which is required by weston, a NULL argument
doesn't do anything.

Signed-off-by: Ran Benita ran...@gmail.com
---
 src/compositor-wayland.c | 3 +--
 src/compositor-x11.c | 3 +--
 src/input.c  | 9 +++--
 src/screen-share.c   | 3 +--
 4 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index 57e850f..5f73c78 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -1464,8 +1464,7 @@ input_handle_keymap(void *data, struct wl_keyboard 
*keyboard, uint32_t format,
else
weston_seat_init_keyboard(input-base, keymap);
 
-   if (keymap)
-   xkb_keymap_unref(keymap);
+   xkb_keymap_unref(keymap);
 
return;
 
diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index 984d799..3494e34 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -322,8 +322,7 @@ x11_input_create(struct x11_compositor *c, int no_input)
keymap = x11_compositor_get_keymap(c);
if (weston_seat_init_keyboard(c-core_seat, keymap)  0)
return -1;
-   if (keymap)
-   xkb_keymap_unref(keymap);
+   xkb_keymap_unref(keymap);
 
x11_compositor_setup_xkb(c);
 
diff --git a/src/input.c b/src/input.c
index 2130789..975cd77 100644
--- a/src/input.c
+++ b/src/input.c
@@ -544,12 +544,10 @@ weston_keyboard_destroy(struct weston_keyboard *keyboard)
 
 #ifdef ENABLE_XKBCOMMON
if (keyboard-seat-compositor-use_xkbcommon) {
-   if (keyboard-xkb_state.state != NULL)
-   xkb_state_unref(keyboard-xkb_state.state);
+   xkb_state_unref(keyboard-xkb_state.state);
if (keyboard-xkb_info)
weston_xkb_info_destroy(keyboard-xkb_info);
-   if (keyboard-pending_keymap)
-   xkb_keymap_unref(keyboard-pending_keymap);
+   xkb_keymap_unref(keyboard-pending_keymap);
}
 #endif
 
@@ -1869,8 +1867,7 @@ weston_xkb_info_destroy(struct weston_xkb_info *xkb_info)
if (--xkb_info-ref_count  0)
return;
 
-   if (xkb_info-keymap)
-   xkb_keymap_unref(xkb_info-keymap);
+   xkb_keymap_unref(xkb_info-keymap);
 
if (xkb_info-keymap_area)
munmap(xkb_info-keymap_area, xkb_info-keymap_size);
diff --git a/src/screen-share.c b/src/screen-share.c
index 9e81ef9..524a0ca 100644
--- a/src/screen-share.c
+++ b/src/screen-share.c
@@ -214,8 +214,7 @@ ss_seat_handle_keymap(void *data, struct wl_keyboard 
*keyboard,
else
weston_seat_init_keyboard(seat-base, keymap);
 
-   if (keymap)
-   xkb_keymap_unref(keymap);
+   xkb_keymap_unref(keymap);
 
return;
 
-- 
2.0.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput 1/4] evdev: Ignore key/button release events if key was never pressed

[Ran Benita]

Hi Jonas,

On Sun, Jul 27, 2014 at 11:28:28PM +0200, Jonas Ådahl wrote:
 The kernel may send a 'release' event without ever having sent a key
 'pressed' event in case the key was pressed before libinput was
 initiated. Ignore these events so that we always guarantee a release
 event always comes after a pressed event for any given key or button.

Would it be possible to describe in the docs the invariants that
libinput is keeping w.r.t. key press/release ordering and count?
If the user can rely on such invariants, it can simplify how he
interfaces with e.g. libxkbcommon, which expects a coherent key event
stream (things like modifier press with a missed release can cause some
fun).

Ran

 Signed-off-by: Jonas Ådahl jad...@gmail.com
 ---
  src/evdev.c | 33 -
  src/evdev.h |  2 ++
  src/libinput-util.h | 29 +
  test/keyboard.c | 52 
  4 files changed, 115 insertions(+), 1 deletion(-)
 
 diff --git a/src/evdev.c b/src/evdev.c
 index 5872856..0f4874c 100644
 --- a/src/evdev.c
 +++ b/src/evdev.c
 @@ -47,6 +47,18 @@ enum evdev_key_type {
   EVDEV_KEY_TYPE_BUTTON,
  };
  
 +static void
 +set_key_pressed(struct evdev_device *device, int code, int pressed)
 +{
 + long_set_bit_state(device-key_mask, code, pressed);
 +}
 +
 +static int
 +is_key_pressed(struct evdev_device *device, int code)
 +{
 + return long_bit_is_set(device-key_mask, code);
 +}
 +
  void
  evdev_device_led_update(struct evdev_device *device, enum libinput_led leds)
  {
 @@ -294,6 +306,8 @@ static inline void
  evdev_process_key(struct evdev_device *device,
 struct input_event *e, uint64_t time)
  {
 + enum evdev_key_type type;
 +
   /* ignore kernel key repeat */
   if (e-value == 2)
   return;
 @@ -306,7 +320,24 @@ evdev_process_key(struct evdev_device *device,
  
   evdev_flush_pending_event(device, time);
  
 - switch (get_key_type(e-code)) {
 + type = get_key_type(e-code);
 +
 + /* Ignore key release events from the kernel for keys that libinput
 +  * never got a pressed event for. */
 + if (e-value == 0) {
 + switch (type) {
 + case EVDEV_KEY_TYPE_NONE:
 + break;
 + case EVDEV_KEY_TYPE_KEY:
 + case EVDEV_KEY_TYPE_BUTTON:
 + if (!is_key_pressed(device, e-code))
 + return;
 + }
 + }
 +
 + set_key_pressed(device, e-code, e-value);
 +
 + switch (type) {
   case EVDEV_KEY_TYPE_NONE:
   break;
   case EVDEV_KEY_TYPE_KEY:
 diff --git a/src/evdev.h b/src/evdev.h
 index fad1f84..f71d387 100644
 --- a/src/evdev.h
 +++ b/src/evdev.h
 @@ -94,6 +94,8 @@ struct evdev_device {
   struct {
   struct motion_filter *filter;
   } pointer;
 +
 + unsigned long key_mask[NLONGS(KEY_CNT)];
  };
  
  #define EVDEV_UNHANDLED_DEVICE ((struct evdev_device *) 1)
 diff --git a/src/libinput-util.h b/src/libinput-util.h
 index c0235ef..2f1a1db 100644
 --- a/src/libinput-util.h
 +++ b/src/libinput-util.h
 @@ -72,6 +72,8 @@ int list_empty(const struct list *list);
pos = tmp, \
tmp = container_of(pos-member.next, tmp, member))
  
 +#define LONG_BITS (sizeof(long) * 8)
 +#define NLONGS(x) (((x) + LONG_BITS - 1) / LONG_BITS)
  #define ARRAY_LENGTH(a) (sizeof (a) / sizeof (a)[0])
  #define ARRAY_FOR_EACH(_arr, _elem) \
   for (size_t _i = 0; (_elem = _arr[_i])  _i  ARRAY_LENGTH(_arr); 
 _i++)
 @@ -150,4 +152,31 @@ vector_get_direction(int dx, int dy)
   return dir;
  }
  
 +static inline int
 +long_bit_is_set(const unsigned long *array, int bit)
 +{
 +return !!(array[bit / LONG_BITS]  (1LL  (bit % LONG_BITS)));
 +}
 +
 +static inline void
 +long_set_bit(unsigned long *array, int bit)
 +{
 +array[bit / LONG_BITS] |= (1LL  (bit % LONG_BITS));
 +}
 +
 +static inline void
 +long_clear_bit(unsigned long *array, int bit)
 +{
 +array[bit / LONG_BITS] = ~(1LL  (bit % LONG_BITS));
 +}
 +
 +static inline void
 +long_set_bit_state(unsigned long *array, int bit, int state)
 +{
 + if (state)
 + long_set_bit(array, bit);
 + else
 + long_clear_bit(array, bit);
 +}
 +
  #endif /* LIBINPUT_UTIL_H */
 diff --git a/test/keyboard.c b/test/keyboard.c
 index a55405c..a7f500c 100644
 --- a/test/keyboard.c
 +++ b/test/keyboard.c
 @@ -112,10 +112,62 @@ START_TEST(keyboard_seat_key_count)
  }
  END_TEST
  
 +START_TEST(keyboard_ignore_no_pressed_release)
 +{
 + struct litest_device *dev;
 + struct libinput *libinput;
 + struct libinput_event *event;
 + struct libinput_event_keyboard *kevent;
 + int events[] = {
 + EV_KEY, KEY_A,
 + -1, -1,
 + };
 + enum libinput_key_state *state;
 + enum libinput_key_state expected_states[] = {
 + 

Re: [PATCH libinput 1/2] Make context reference counted

[Ran Benita]

On Mon, Jun 23, 2014 at 11:56:41PM +0200, Jonas Ådahl wrote:
 Instead of only allowing one owner keeping a libinput context alive,
 make context reference counted, replacing libinput_destroy() with
 libinput_unref() while adding another function libinput_ref().
 
 Even though there might not be any current use cases, it doesn't mean we
 should hard code this usage model in the API. The old behaviour can be
 emulated by never calling libinput_ref() while replacing
 libinput_destroy() with libinput_unref().
 
 Signed-off-by: Jonas Ådahl jad...@gmail.com
 ---
 
 There are no users I know of which currently would benefit from this but
 I'm thinking it might be better to at least not disallow. Yay or nay?
 
 Jonas
 
  src/libinput-private.h |  1 +
  src/libinput.c | 14 +-
  src/libinput.h | 25 ++---
  src/udev-seat.c|  2 +-
  test/keyboard.c|  2 +-
  test/litest.c  |  2 +-
  test/log.c | 10 +-
  test/misc.c| 10 +-
  test/path.c| 20 ++--
  test/pointer.c |  2 +-
  test/udev.c| 16 
  tools/event-debug.c|  4 ++--
  tools/event-gui.c  |  2 +-
  13 files changed, 71 insertions(+), 39 deletions(-)
 
 diff --git a/src/libinput-private.h b/src/libinput-private.h
 index f0bda1f..cfe6535 100644
 --- a/src/libinput-private.h
 +++ b/src/libinput-private.h
 @@ -57,6 +57,7 @@ struct libinput {
   const struct libinput_interface *interface;
   const struct libinput_interface_backend *interface_backend;
   void *user_data;
 + int refcount;
  };
  
  typedef void (*libinput_seat_destroy_func) (struct libinput_seat *seat);
 diff --git a/src/libinput.c b/src/libinput.c
 index c4f7fe1..d3e2149 100644
 --- a/src/libinput.c
 +++ b/src/libinput.c
 @@ -502,6 +502,7 @@ libinput_init(struct libinput *libinput,
   libinput-interface = interface;
   libinput-interface_backend = interface_backend;
   libinput-user_data = user_data;
 + libinput-refcount = 1;
   list_init(libinput-source_destroy_list);
   list_init(libinput-seat_list);
  
 @@ -531,7 +532,13 @@ libinput_drop_destroyed_sources(struct libinput 
 *libinput)
  }
  
  LIBINPUT_EXPORT void
 -libinput_destroy(struct libinput *libinput)
 +libinput_ref(struct libinput *libinput)

How about making this function return its argument? Often you have code
like

void obj_new(struct libinput *libinput)
{
[...]
obj-libinput = libinput;
libinput_ref(libinput);
[...]
}

I think this is better:

obj-libinput = libinput_ref(libinput);

Ran

 +{
 + libinput-refcount++;
 +}
 +
 +LIBINPUT_EXPORT void
 +libinput_unref(struct libinput *libinput)
  {
   struct libinput_event *event;
   struct libinput_device *device, *next_device;
 @@ -540,6 +547,11 @@ libinput_destroy(struct libinput *libinput)
   if (libinput == NULL)
   return;
  
 + assert(libinput-refcount  0);
 + libinput-refcount--;
 + if (libinput-refcount  0)
 + return;
 +
   libinput_suspend(libinput);
  
   libinput-interface_backend-destroy(libinput);
 diff --git a/src/libinput.h b/src/libinput.h
 index b1b1124..1eada8f 100644
 --- a/src/libinput.h
 +++ b/src/libinput.h
 @@ -793,6 +793,9 @@ struct libinput_interface {
   * device are ignored. Such devices and those that failed to open
   * ignored until the next call to libinput_resume().
   *
 + * The reference count of the context is initialized to 1. See @ref
 + * libinput_unref.
 + *
   * @param interface The callback interface
   * @param user_data Caller-specific data passed to the various callback
   * interfaces.
 @@ -818,6 +821,9 @@ libinput_udev_create_for_seat(const struct 
 libinput_interface *interface,
   * The context is fully initialized but will not generate events until at
   * least one device has been added.
   *
 + * The reference count of the context is initialized to 1. See @ref
 + * libinput_unref.
 + *
   * @param interface The callback interface
   * @param user_data Caller-specific data passed to the various callback
   * interfaces.
 @@ -967,13 +973,26 @@ libinput_suspend(struct libinput *libinput);
  /**
   * @ingroup base
   *
 - * Destroy the libinput context. After this, object references associated 
 with
 - * the destroyed context are invalid and may not be interacted with.
 + * Add a reference to the context. A context is destroyed whenever the
 + * reference count reaches 0. See @ref libinput_unref.
 + *
 + * @param libinput A previously initialized valid libinput context
 + */
 +void
 +libinput_ref(struct libinput *libinput);
 +
 +/**
 + * @ingroup base
 + *
 + * Dereference the libinput context. After this, the context may have been
 + * destroyed, if the last reference was dereferenced. If so, the context is
 + * invalid and may not be interacted with. It is up to the caller to keep
 + * track of the number of references 

[ANNOUNCE] libxkbcommon 0.4.2

[Ran Benita]

Contains a build fix and other small changes.


libxkbcommon 0.4.2 - 2014-05-15
==

- Fixed a bug where explicitly passing --enable-x11 to ./configure would
  in fact disable it (regressed in 0.4.1).

- Added @since version annotations to the API documentation for everything
  introduced after the initial stable release (0.2.0).

- Added a section to the documentation about keysym transformations, and
  clarified which functions perform a given transformation.

- XKB files which fail to compile during keymap construction can no longer
  have any effect on the resulting keymap: changes are only applied when
  the entire compilation succeeds.
  Note: this was a minor correctness issue inherited from xkbcomp.

- Fix an out-of-bounds array access in src/x11/util.c:adopt_atoms()
  error-handling code.
  Note: it seems impossible to trigger in the current code since the input
  size cannot exceed the required size.


Tarballs:


git tag: xkbcommon-0.4.2

http://xkbcommon.org/download/libxkbcommon-0.4.2.tar.xz
MD5:  4b717adce41c8305258e99a9b396330a  libxkbcommon-0.4.2.tar.xz
SHA1: 63eaa8624ec9bcc209e281193fb2db35a28b0246  libxkbcommon-0.4.2.tar.xz

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon-0.4.1

[Ran Benita]

We've accumulated some changes and bug fixes, so here's a new release.

libxkbcommon 0.4.1
==

- Converted README to markdown and added a Quick Guide to the
  documentation, which breezes through the most common parts of
  xkbcommon.
  Link: http://xkbcommon.org/doc/current/md_doc_quick-guide.html

- Added two new functions, xkb_state_key_get_utf{8,32}(). They
  combine the operations of xkb_state_key_get_syms() and
  xkb_keysym_to_utf{8,32}(), and provide a nicer interface for it
  (espcially for multiple-keysyms-per-level).

- The xkb_state_key_get_utf{8,32}() functions now apply Control
  transformation: when the Control modifier is active, the string
  is converted to an appropriate control character.
  This matches the behavior of libX11's XLookupString(3), and
  required by the XKB specification:
  
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Interpreting_the_Control_Modifier

  https://bugs.freedesktop.org/show_bug.cgi?id=75892

- The consumed modifiers for a key are now calculated similarly
  to libX11. The previous behavior caused a bug where Shift would
  not cancel an active Caps Lock.

- Make xkbcommon-x11 work with the keymap reported by the XQuartz
  X server.

  https://bugs.freedesktop.org/show_bug.cgi?id=75798

- Reduce memory usage during keymap compilation some more.

- New API:
  xkb_state_key_get_consumed_mods()
  xkb_state_key_get_utf8()
  xkb_state_key_get_utf32()

- Deprecated API:
  XKB_MAP_COMPILE_PLACEHOLDER, XKB_MAP_NO_FLAGS
use XKB_KEYMAP_NO_FLAGS instead.

- Bug fixes.


Tarballs:


git tag: xkbcommon-0.4.1

http://xkbcommon.org/download/libxkbcommon-0.4.1.tar.xz
MD5:  b70f4ed97b6c9432dc956e4177f3336a  libxkbcommon-0.4.1.tar.xz
SHA1: 38814e7edea16d032463b853490dda9040e5b1  libxkbcommon-0.4.1.tar.xz

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [ANNOUNCE] libxkbcommon-0.4.1

[Ran Benita]

On Thu, Mar 27, 2014 at 09:04:07PM +0100, David Herrmann wrote:
 Hi

Hi David

 On Thu, Mar 27, 2014 at 8:22 PM, Ran Benita ran...@gmail.com wrote:
  - Added two new functions, xkb_state_key_get_utf{8,32}(). They
combine the operations of xkb_state_key_get_syms() and
xkb_keysym_to_utf{8,32}(), and provide a nicer interface for it
(espcially for multiple-keysyms-per-level).
 
 Slightly off-topic, but looking at the code, you ignore any multi-sym
 values (nsyms != 1). Users of that API might rely on that behavior, so
 have we at some point defined what exactly multi-sym means? Because if
 we add more and more APIs and if the user-base grows, we might at some
 point be unable to make use of multi-symbol behavior. I'm still not
 sure whether nsyms  1 just means multiple sequential keysyms, or
 whether they should be handled as _one_ atomic combined keysym?

First, the reason I added these functions is that
https://bugs.freedesktop.org/show_bug.cgi?id=75892 made it necessary, I
would otherwise like to avoid adding new API at this point. But given
the situation, I tried to make the best of it.

I only ignore multiple-keysyms for the utf32 function -- I only added
it to match the existing xkb_keysym_to_utf32() function. I don't think
it makes sense to encode multiple-keysyms into a UTF-32 string, nobody
uses it. A better name would be xkb_keysym_to_unicode_codepoint() or
whatever, but I wanted to keep the existing name.

For the utf8 function, it is handled correctly, and is actually much
easier to use for multiple-keysyms than the old function. It builds the
string internally and finally ensures it's valid UTF-8.

Another advantage of adding new functions is that existing users don't
break due to the new behavior, they must opt-in.

Regarding intended use-case for multiple-keysyms, I consider it mainly
to be for sequences with combining characters - not everything has
precomposed codepoints, so if you want one of these, you don't have a
way to do it with single-keysym, but it still conceptually fits in a
keymap. However for the original intent you have to ask Daniel.

  - The xkb_state_key_get_utf{8,32}() functions now apply Control
transformation: when the Control modifier is active, the string
is converted to an appropriate control character.
This matches the behavior of libX11's XLookupString(3), and
required by the XKB specification:

  http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Interpreting_the_Control_Modifier
 
https://bugs.freedesktop.org/show_bug.cgi?id=75892
 
 So xkb_state_key_get_utf8(state, code) !=
 xkb_keysym_to_utf8(xkb_state_key_get_one_sym(state, code))? (at least
 for ctrl+char)

Yes.

 Could we at least add a note/warning to the documentation? I cannot
 find anything here:
 http://xkbcommon.org/doc/current/group__state.html#ga0774b424063b45c88ec0354c77f9a247
 
 For instance, for libtsm, I accept combined modifier+keysym+ucs4string
 input from the GUI layer and transform that internally. If the upper
 layer uses xkb_state_key_get_utf32() instead of xkb_keysym_to_utf32(),
 the logic will force the control-seq even though it might be mapped
 differently by the vte-layer (for instance, there's stuff like
 shifting values by 64 if ALT is pressed, and more legacy crap we need
 to support for eternity). Sure, most libtsm code uses the keysym, but
 for glyph transformation we have to use the ucs4 value. Imagine the
 ctrl+c input was shifted by the term-layer, you still end up with the
 \003 glyph, because the ucs4 string was mapped by xkbcommon.

Sure, the old functions are still useful for getting the raw
translation if you want it. And you're right about the docs - I'll add
some hopefully-not-too-confusing details instead of just prefer the new
ones. Full details are in the bugs and commit msgs but of course I
don't expect anyone to read that :)

 I'm not saying the patch is wrong, in fact, the layout-search logic is
 actually what you wrote for kmscon and I appreciate that. I'm just
 saying that it's a really subtle API difference that can introduce
 weird bugs. Lets see how it works out, but if people start using
 xkb_state_key_get_utf32(), I might send a patch adding an xkb-state
 flag that disables this transformation. Or just force users to not use
 it (which would be unfortunate).

A flag makes sense; I try to to add stuff when someone really needs it,
not preemptively. Btw, xkb_state_new() doesn't take a flags arg - argh.

But in general this stuff should be the default, we initially tried to
avoid these nonsensical US-centric behavior (let's say intentionally :),
but both the keymaps and existing users actually depend on them, like
the capitalization and Control thing (and they are also there in the
spec).

 Btw., same is true for the implicit caps-lock magic in
 xkb_state_key_get_one_sym(). I'm now quite confused whether
 xkb_state_key_get_syms() users have to do caps-lock handling
 explicitly? Or is that done by keymaps?

Currently

[ANNOUNCE] libxkbcommon 0.3.2

[Ran Benita]

Hi,

libxkbcommon 0.3.2 is released. This is primarily a bug-fix release, and
everyone is recommended to update.

Note for builders and distributors:
--

The build dependencies of libxkbcommon have reduced over several
releases. Currently, they are:

- bison OR a recent byacc
  A pre-generated file is included in the tarball if one is not
  available.
- xkeyboard-config
  For finding the XKB data root path (the path can be passed manually).

When building from git, you also need:
- xorg-util-macros = 1.16

There are no runtime dependencies, though xkeyboard-config or another
XKB dataset is needed for using keymaps.

Note for users:
--

Due to a bug report[1], there now exists a slightly unfortunate difference
between the two functions xkb_state_key_get_one_sym(), and
xkb_state_key_get_syms() with a return value of 1 (indicating one keysym
is returned). The former now performs a capitalization transformation
on the keysym[2], while the latter does not.

Therefore, if your application does not utilize the multiple-keysyms
support in libxkbcommon, consider using xkb_state_key_get_one_sym()
rather than xkb_state_key_get_syms().

Hopefully, we can remove such implicit behavior from all of
xkeyboard-config's keymaps in the future, thus making such subtleties
irrelevant.

Other changes:

- Added XKB_KEY_XF86AudioMicMute keysym, to match xproto 7.0.24.

- Log messages from the library now look like xkbcommon: ERROR by
  default, instead of xkbcomp-like Error:   .

[1] https://bugs.freedesktop.org/show_bug.cgi?id=67167
[2] 
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Interpreting_the_Lock_Modifier

Tarballs:


git tag: xkbcommon-0.3.2

http://xkbcommon.org/download/libxkbcommon-0.3.2.tar.xz
MD5:  935cf416354bf05210de2e389484f7e8  libxkbcommon-0.3.2.tar.xz
SHA1: 7bfe39fef420d072a84fd295f0c5bb049f8d30b9  libxkbcommon-0.3.2.tar.xz

Thanks,
Ran and Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] Add a way to update the keymap

[Ran Benita]

On Thu, Oct 10, 2013 at 07:53:12PM +0200, Rui Tiago Cação Matos wrote:
 Hi,
 
 On 7 October 2013 20:16, Ran Benita ran...@gmail.com wrote:
  At least retaining the locked modifiers (and therefore the LED state in
  most cases) would be nice, and not too problematic I think (though some
  edge cases are expected).
 
 Ok, the new version keeps both latched and locked modifiers.
 
  (Also, the keymap updating in compositor-x11 is currently not optimal, we
  should really be listening for XKB protocol events rather than the
  rules property changes. But this is pending an XCB release at least,
  which I can only hope will happen sometime this decade :)
 
 Hmm, is there even a way to get the RMLVO from the server with XKB? I
 thought the root window property was the only way to get it. Even
 setxkbmap calls XkbRF_SetNamesProp() and uses the property all over.

Since you asked :)

No, there isn't a formal way besides the property convention.
What I meant is to use the XKB protocol itself to get all the keymap info
from the server, then you don't compile anything on the client. Strictly
speaking this is necessary, since if the client and server are on
different machines, then the RMLVO may mean entirely different things for
both of them. When you use xkb_keymap_new_from_rules(), you are
compiling a keymap with the client's keymap file/xkeyboard-config files,
while if you use the XKB protocol / Xlib you are working off the server's
keymap.

setxkbmap only sets the propery as far I remember. It uses
XkbGetKbdByName to upload the keymap structure that it compiles locally
to the server (yes, GetKbd to set the keymap...). Wayland doesn't have
setxkbmap functionality currently, and when it does it'll be much simpler
since you don't have the entire network-transparency issue.

Xlib on the other hand fetches the keymap (with XkbGetMap request) from
the server and keeps it in sync; this is what we should do as well if we
want to play nice with the X architecture and how it was meant to be
used.

I already have it implemented in a xkbcommon-x11 helper library, but
I'm waiting for an XCB release and some polishing. I've pushed my branch
to the main repo now, you can look e.g. here if you're interested:
https://github.com/xkbcommon/libxkbcommon/blob/xcb-wip/xkbcommon/xkbcommon-x11.h
https://github.com/xkbcommon/libxkbcommon/blob/xcb-wip/test/interactive-x11.c
Anyway it would take a long time until it gets to distributions.

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH xkbcommon] keysym-utf: Fix a warning about shadowing

[Ran Benita]

On Mon, Oct 07, 2013 at 02:11:36PM +0530, Siddharth Heroor wrote:
 Change variable names to avoid the name clash. The warning seen is
 
 src/keysym-utf.c: In function 'bin_search':
 src/keysym-utf.c:841: warning: declaration of 'min' shadows a global 
 declaration
 src/utils.h:109: warning: shadowed declaration is here
 src/keysym-utf.c:842: warning: declaration of 'max' shadows a global 
 declaration
 src/utils.h:115: warning: shadowed declaration is here
 
 Signed-off-by: Siddharth Heroor her...@ti.com

Applied, thanks.

Ran

 ---
  src/keysym-utf.c |   12 ++--
  1 files changed, 6 insertions(+), 6 deletions(-)
 
 diff --git a/src/keysym-utf.c b/src/keysym-utf.c
 index 5484a83..9a96053 100644
 --- a/src/keysym-utf.c
 +++ b/src/keysym-utf.c
 @@ -838,20 +838,20 @@ static const struct codepair keysymtab[] = {
  static uint32_t
  bin_search(const struct codepair *table, size_t length, xkb_keysym_t keysym)
  {
 -int min = 0;
 -int max = length;
 +int first = 0;
 +int last = length;
  int mid;
  
  if (keysym  table[0].keysym  || keysym  table[length].keysym)
  return 0;
  
  /* binary search in table */
 -while (max = min) {
 -mid = (min + max) / 2;
 +while (last = first) {
 +mid = (first + last) / 2;
  if (table[mid].keysym  keysym)
 -min = mid + 1;
 +first = mid + 1;
  else if (table[mid].keysym  keysym)
 -max = mid - 1;
 +last = mid - 1;
  else /* found it */
  return table[mid].ucs;
  }
 -- 
 1.7.0.4
 
 ___
 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

Re: [xkbcommon] Use an integer type for modifiers bit mask.

[Ran Benita]

On Fri, Oct 04, 2013 at 03:22:59PM +0200, David Herrmann wrote:
 Hi
 
 On Fri, Oct 4, 2013 at 2:34 PM, Daniel Stone dan...@fooishbar.org wrote:
  On 4 October 2013 13:09, Wander Lairson Costa wander.lair...@gmail.com 
  wrote:
  That's what the patch is about: avoid casts. Whenever you use a cast,
  you are giving up the help the compiler may give to you regarding
  invalid type conversions. So, I always use the rule of thumb of
  avoiding casts whenever I can. IMO, this is not a harmful patch and
  will make the C++ programmers a little bit easier.
 
  I can see where it's going, but on the other hand xkb_mod_mask_t is
  _so_ not the right type.  That's a bitmask of actual modifiers (i.e.
  the return value), not a bitmask of components.  So it avoids the
  cast, but also makes the API look extremely misleading, as we've
  documented exactly what xkb_mod_mask_t is.
 
  I really like the type safety aspect, so to be honest I'm just
  inclined to make C++ wear the cast for now.
 
 We had a similar discussion when I pointed out that enum may change
 the underlying type without notice when adding new enum-values.

Just adding a note that this problem can be mitigated by adding some
dummy value to the enum to force it to be int-sized. Of course we can't
do it in xkbcommon, but future APIs may want to do this, at least if
they don't find it too ugly.

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [xkbcommon] Make C++ happy.

[Ran Benita]

On Thu, Sep 26, 2013 at 09:35:33AM -0300, Wander Lairson Costa wrote:
 For most functions taking an enum flags parameter, we use 0 value to
 indicate that no flags should be applied.
 
 C++ has a stronger type system than C and will not implicitly convert
 int's to enum's. Thus, we create valid 0 enum values for enum types
 where it makes sense.

Thanks!
I just made a few changes (see below) and applied; I hope you don't
mind.

 
 Signed-off-by: Wander Lairson Costa wander.lair...@gmail.com
 ---
  xkbcommon/xkbcommon.h | 9 +
  1 file changed, 9 insertions(+)
 
 diff --git a/xkbcommon/xkbcommon.h b/xkbcommon/xkbcommon.h
 index 1480b1b..4627cea 100644
 --- a/xkbcommon/xkbcommon.h
 +++ b/xkbcommon/xkbcommon.h
 @@ -360,6 +360,8 @@ xkb_keysym_get_name(xkb_keysym_t keysym, char *buffer, 
 size_t size);
  
  /** Flags for xkb_keysym_from_name(). */
  enum xkb_keysym_flags {
 +/** Do not apply any flag. */
 +XKB_KEYSYM_NO_FLAG = 0,

FLAG - FLAGS

  /** Find keysym by case-insensitive search. */
  XKB_KEYSYM_CASE_INSENSITIVE = (1  0)
  };
 @@ -425,6 +427,8 @@ xkb_keysym_to_utf32(xkb_keysym_t keysym);
  
  /** Flags for context creation. */
  enum xkb_context_flags {
 +/** Do not apply any context flag. */
 +XKB_CONTEXT_NO_FLAG = 0,

FLAG - FLAGS

  /** Create this context with an empty include path. */
  XKB_CONTEXT_NO_DEFAULT_INCLUDES = (1  0),
  /** Don't take RMLVO names from the environment. */
 @@ -577,6 +581,7 @@ xkb_context_include_path_get(struct xkb_context *context, 
 unsigned int index);
  
  /** Specifies a logging level. */
  enum xkb_log_level {
 +XKB_LOG_LEVEL_NO_LOG = 0,/** No log. */

This one's not needed, you can't pass/get that.

  XKB_LOG_LEVEL_CRITICAL = 10, /** Log critical internal errors only. */
  XKB_LOG_LEVEL_ERROR = 20,/** Log all errors. */
  XKB_LOG_LEVEL_WARNING = 30,  /** Log warnings and errors. */
 @@ -676,6 +681,8 @@ xkb_context_set_log_fn(struct xkb_context *context,
  
  /** Flags for keymap compilation. */
  enum xkb_keymap_compile_flags {
 +/** Do not apply any flag. */
 +XKB_MAP_COMPILE_NO_FLAG = 0,

FLAG - FLAGS

  /** Apparently you can't have empty enums.  What a drag. */
  XKB_MAP_COMPILE_PLACEHOLDER = 0
  };
 @@ -708,6 +715,8 @@ xkb_keymap_new_from_names(struct xkb_context *context,
  
  /** The possible keymap formats. */
  enum xkb_keymap_format {
 +/** No format. */
 +XKB_KEYMAP_FORMAT_NONE = 0,

This one's not needed, you can't pass/get that.

Ran

  /** The current/classic XKB text format, as generated by xkbcomp -xkb. */
  XKB_KEYMAP_FORMAT_TEXT_V1 = 1
  };
 -- 
 1.8.1.2
 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [xkbcommon] How to distinguish left-shift and right-shift

[Ran Benita]

On Thu, Sep 26, 2013 at 08:49:24AM -0300, Wander Lairson Costa wrote:
 2013/9/25 Ran Benita ran...@gmail.com:
  On Tue, Sep 24, 2013 at 08:02:30PM -0300, Wander Lairson Costa wrote:
  Hi,
 
 
  Hi,
 
  I am working for some time porting Blender to wayland [1] and I am now
  adding keyboard handing support. For that, I am following weston
  clients code as reference and using libxkbcommon.
 
  To make a long history short, I need to differentiate left-shift and
  right-shift modifiers, but I didn't figure out how to do that with
  libxkbcommon. I printed all modifiers names and there is just one
  Shift modifier, there aren't LShift and RShift like there are
  for control and alt key modifiers.
 
  I'm afraid we have no way to do that. We currently only expose the 8 old
  X11 modifiers, which only have Shift. There are also what's called
  virtual modifiers, which I have some pending work to expose, but these
  *too* don't have separate RShift and LShift modifiers (as opposed to
  e.g. LControl and RControl) - that's in current xkeyboard-config, which
  is the project where all the keyboard data is maintained. And there was
  some sensible resistence to addings these, for example here:
  https://bugs.freedesktop.org/show_bug.cgi?id=50935#c18
 
  Of course, X11/XKB is in exactly the same boat here, so I from a quick
  look I found that what the blender X11 backend does (as far as I can
  see), is that it gets the key state with the XQueryKeymap(3) request,
  and then sees if the left/right *keys* are down. That's not entirely
  correct purely speaking, but I guess it works in 99.% percent of the
  cases. So I can only suggest you do the same for now for Wayland.
 
  But... xkbcommon doesn't (and prefereably won't) expose an equivalent of
  XQueryKeymap itself, and the Wayland protocol only provides it on the
  wl_keyboard enter event (with the 'keys' field). So unfortunatly what
  you have do is get/reset this array on wl_keyboard enter event, and
  keep it updated manually on the client side on key events. That should
  work... Unless someone has a better idea!
 
 
 Initially I thought to handle this in the key event (maybe only for
 shift key). I just don't which would be the best solution...

The information you need, if you want to use the key-down approach
(which is the only one I can think of), is whether e.g. the Left Shift
key is down at any given moment. This keys-state information is kept on
the compositor, but now you need to reconstruct it on the client. The
way to do it is as I outlined above, i.e. wl_keyboard.enter event, which
gives you a wl_array of all the keys which are pressed +
wl_keyboard.key events, which allow you to keep this array in sync.

(Though by a quick look at the Weston code, it might be that it sends
key-down events for all the keys which are down when the focus is
changed, that is, it replays what happened to get to the current state.
So maybe you don't need the information in the wl_keyboard.enter after
all, only the key events with an initial empty array. It should be easy
to check which way is it).

Ran

 
  Sorry!
  Ran
 
 
  [1] https://github.com/walac/blender-wayland
 
  --
  Best Regards,
  Wander Lairson Costa
  ___
  wayland-devel mailing list
  wayland-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/wayland-devel
 
 
 
 -- 
 Best Regards,
 Wander Lairson Costa
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [xkbcommon] How to distinguish left-shift and right-shift

[Ran Benita]

On Thu, Sep 26, 2013 at 04:00:15PM -0300, Wander Lairson Costa wrote:
 2013/9/26 Ran Benita ran...@gmail.com:
 
 [snip]
 
 
  The information you need, if you want to use the key-down approach
  (which is the only one I can think of), is whether e.g. the Left Shift
  key is down at any given moment. This keys-state information is kept on
  the compositor, but now you need to reconstruct it on the client. The
  way to do it is as I outlined above, i.e. wl_keyboard.enter event, which
  gives you a wl_array of all the keys which are pressed +
  wl_keyboard.key events, which allow you to keep this array in sync.
 
 
 This is what I was thinking about.
 
  (Though by a quick look at the Weston code, it might be that it sends
  key-down events for all the keys which are down when the focus is
  changed, that is, it replays what happened to get to the current state.
  So maybe you don't need the information in the wl_keyboard.enter after
  all, only the key events with an initial empty array. It should be easy
  to check which way is it).
 
 
 But this is an weston implementation detail, I guess, other
 compositors may not have the same behavior.

Good point, I can't find it specified either. I think whatever the
current behavior is, it should be specified in wayland.xml, so people can
rely on it. In some cases, such undefined behavior can be a real
hinderance, for example if you want to keep a 'press-count' for a key
(there can be cases like two keyboards in the same seat, so *two* Left
Shift keys can be down at the same time, etc). And since Wayland will
have many compositors, you don't have a de facto standard like X server,
and they *will* do it differently, I expect...

So if you see what happens exactly, it'd be nice if you open a bug, or
post back, or send a patch :)

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [xkbcommon] How to distinguish left-shift and right-shift

[Ran Benita]

On Thu, Sep 26, 2013 at 06:27:39PM -0300, Wander Lairson Costa wrote:
 2013/9/26 Ran Benita ran...@gmail.com:
  On Thu, Sep 26, 2013 at 04:00:15PM -0300, Wander Lairson Costa wrote:
  2013/9/26 Ran Benita ran...@gmail.com:
 
  [snip]
 
  
   The information you need, if you want to use the key-down approach
   (which is the only one I can think of), is whether e.g. the Left Shift
   key is down at any given moment. This keys-state information is kept on
   the compositor, but now you need to reconstruct it on the client. The
   way to do it is as I outlined above, i.e. wl_keyboard.enter event, which
   gives you a wl_array of all the keys which are pressed +
   wl_keyboard.key events, which allow you to keep this array in sync.
  
 
  This is what I was thinking about.
 
   (Though by a quick look at the Weston code, it might be that it sends
   key-down events for all the keys which are down when the focus is
   changed, that is, it replays what happened to get to the current state.
   So maybe you don't need the information in the wl_keyboard.enter after
   all, only the key events with an initial empty array. It should be easy
   to check which way is it).
  
 
  But this is an weston implementation detail, I guess, other
  compositors may not have the same behavior.
 
  Good point, I can't find it specified either. I think whatever the
  current behavior is, it should be specified in wayland.xml, so people can
  rely on it. In some cases, such undefined behavior can be a real
  hinderance, for example if you want to keep a 'press-count' for a key
  (there can be cases like two keyboards in the same seat, so *two* Left
  Shift keys can be down at the same time, etc). And since Wayland will
  have many compositors, you don't have a de facto standard like X server,
  and they *will* do it differently, I expect...
 
 
 This kind of undefined behavior does not happen only on this case.
 
 For example, I have been wondering about window decoration. AFAIK,
 Wayland leaves to the compositor thr decision if window decoration should be
 client side or server side. In weston, it is client side, KWin will be
 server side, how an application would know if it has to decorate its
 own window or not?
 (This is a more general question that may deserve its own thread)

I'm not a Wayland developer, so I can't say with confidence. But I think
this choice is deferred to the toolkit layer. In this case both
behaviors (server of client side decorations) are potentially useful, so
the protocol shouldn't *require* one or the other. Though I guess for the
issue you mentioned, maybe there should be some protocol to tell the
client whether it should draw decorations or not.

But this is not the case for the key-replay behavior. There's nothing to
be gained by letting different compositors do different things in this
case. Both behaviors are fine IMO, so should just require whatever
Weston does currently.

 
  So if you see what happens exactly, it'd be nice if you open a bug, or
  post back, or send a patch :)
 
 Do you mean about the behavior when we have more than one keyboard
 attached to a seat?

No, that should work seamlessly. I meant the replay of the key press
events (after you manage to implement your stuff in a real world
application like Blender).

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [xkbcommon] How to distinguish left-shift and right-shift

[Ran Benita]

On Tue, Sep 24, 2013 at 08:02:30PM -0300, Wander Lairson Costa wrote:
 Hi,
 

Hi,

 I am working for some time porting Blender to wayland [1] and I am now
 adding keyboard handing support. For that, I am following weston
 clients code as reference and using libxkbcommon.
 
 To make a long history short, I need to differentiate left-shift and
 right-shift modifiers, but I didn't figure out how to do that with
 libxkbcommon. I printed all modifiers names and there is just one
 Shift modifier, there aren't LShift and RShift like there are
 for control and alt key modifiers.

I'm afraid we have no way to do that. We currently only expose the 8 old
X11 modifiers, which only have Shift. There are also what's called
virtual modifiers, which I have some pending work to expose, but these
*too* don't have separate RShift and LShift modifiers (as opposed to
e.g. LControl and RControl) - that's in current xkeyboard-config, which
is the project where all the keyboard data is maintained. And there was
some sensible resistence to addings these, for example here:
https://bugs.freedesktop.org/show_bug.cgi?id=50935#c18

Of course, X11/XKB is in exactly the same boat here, so I from a quick
look I found that what the blender X11 backend does (as far as I can
see), is that it gets the key state with the XQueryKeymap(3) request,
and then sees if the left/right *keys* are down. That's not entirely
correct purely speaking, but I guess it works in 99.% percent of the
cases. So I can only suggest you do the same for now for Wayland.

But... xkbcommon doesn't (and prefereably won't) expose an equivalent of
XQueryKeymap itself, and the Wayland protocol only provides it on the
wl_keyboard enter event (with the 'keys' field). So unfortunatly what
you have do is get/reset this array on wl_keyboard enter event, and
keep it updated manually on the client side on key events. That should
work... Unless someone has a better idea!

Sorry!
Ran

 
 [1] https://github.com/walac/blender-wayland
 
 -- 
 Best Regards,
 Wander Lairson Costa
 ___
 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

Re: [PATCH libxkbcommon] keymap: add xkb_keymap_new_from_memory()

[Ran Benita]

On Wed, Mar 13, 2013 at 07:28:17PM +0200, Ran Benita wrote:
 On Mon, Mar 11, 2013 at 12:53:39PM +0100, David Herrmann wrote:
  The current API doesn't allow the caller to create keymaps from mmap()'ed
  files. The problem is, xkb_keymap_new_from_string() requires a terminating
  0 byte. However, there is no way to guarantee that when using mmap() so a
  user currently has to copy the whole file just to get the terminating zero
  byte (assuming they cannot use xkb_keymap_new_from_file()).
  
  This adds a new entry xkb_keymap_new_from_memory() which takes a memory
  location and the size in bytes.
  
  Internally, we depend on yy_scan_{string,byte}() helpers. According to
  flex documentation these already copy the input string because they are
  wrappers around yy_scan_buffer().
  yy_scan_buffer() on the other hand has some insane requirements. The
  buffer must be writeable and the last two bytes must be ASCII-NUL. But the
  buffer may contain other 0 bytes just fine.
  
  Because we don't want these constraints in our public API,
  xkb_keymap_new_from_memory() needs to create a copy of the input memory.
  But it then calls yy_scan_buffer() directly. Hence, we have the same
  number of buffer-copies as with *_from_string() but without the
  terminating 0 requirement.
  
  Maybe some day we no longer depend on flex and can have a zero-copy API. A
  user could mmap() a file and it would get parsed right from this buffer.
  But until then, we shouldn't expose this limitation in the API but instead
  provide an API that some day can work with zero-copy.
  
  Signed-off-by: David Herrmann dh.herrm...@gmail.com
 
 Patch looks good to me. Too bad we need the extra entry point.
 
 As a side note to your last point: replacing flex is pretty easy, in
 fact I've done it some months ago. I decided against it though because
 flex files are nice and declarative and there wasn't a good reason to
 replace it. But I've done a quick rebase now on top of my working branch
 and your patch:
 https://github.com/bluetech/libxkbcommon/commits/scanner-wip
 Maybe it's worth it now.

I've done a V2 and now I'm happy with it, so no more wip:
https://github.com/bluetech/libxkbcommon/commits/scanner

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libxkbcommon] keymap: add xkb_keymap_new_from_memory()

[Ran Benita]

On Mon, Mar 11, 2013 at 12:53:39PM +0100, David Herrmann wrote:
 The current API doesn't allow the caller to create keymaps from mmap()'ed
 files. The problem is, xkb_keymap_new_from_string() requires a terminating
 0 byte. However, there is no way to guarantee that when using mmap() so a
 user currently has to copy the whole file just to get the terminating zero
 byte (assuming they cannot use xkb_keymap_new_from_file()).
 
 This adds a new entry xkb_keymap_new_from_memory() which takes a memory
 location and the size in bytes.
 
 Internally, we depend on yy_scan_{string,byte}() helpers. According to
 flex documentation these already copy the input string because they are
 wrappers around yy_scan_buffer().
 yy_scan_buffer() on the other hand has some insane requirements. The
 buffer must be writeable and the last two bytes must be ASCII-NUL. But the
 buffer may contain other 0 bytes just fine.
 
 Because we don't want these constraints in our public API,
 xkb_keymap_new_from_memory() needs to create a copy of the input memory.
 But it then calls yy_scan_buffer() directly. Hence, we have the same
 number of buffer-copies as with *_from_string() but without the
 terminating 0 requirement.
 
 Maybe some day we no longer depend on flex and can have a zero-copy API. A
 user could mmap() a file and it would get parsed right from this buffer.
 But until then, we shouldn't expose this limitation in the API but instead
 provide an API that some day can work with zero-copy.
 
 Signed-off-by: David Herrmann dh.herrm...@gmail.com

Patch looks good to me. Too bad we need the extra entry point.

As a side note to your last point: replacing flex is pretty easy, in
fact I've done it some months ago. I decided against it though because
flex files are nice and declarative and there wasn't a good reason to
replace it. But I've done a quick rebase now on top of my working branch
and your patch:
https://github.com/bluetech/libxkbcommon/commits/scanner-wip
Maybe it's worth it now.

Thanks,
Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland] scanner: remove list_length in favor of wl_list_length

[Ran Benita]

---
 src/scanner.c | 16 ++--
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/src/scanner.c b/src/scanner.c
index 6d2eddd..fef85ab 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -127,18 +127,6 @@ struct parse_context {
unsigned int character_data_length;
 };
 
-static int
-list_length(struct wl_list *list)
-{
-   struct wl_list *l;
-   int i;
-
-   for (i = 0, l = list-next; l != list; i++, l = l-next)
-   ;
-
-   return i;
-}
-
 static char *
 uppercase_dup(const char *src)
 {
@@ -1123,13 +,13 @@ emit_code(struct protocol *protocol)
 
if (!wl_list_empty(i-request_list))
printf(\t%d, %s_requests,\n,
-  list_length(i-request_list), i-name);
+  wl_list_length(i-request_list), i-name);
else
printf(\t0, NULL,\n);
 
if (!wl_list_empty(i-event_list))
printf(\t%d, %s_events,\n,
-  list_length(i-event_list), i-name);
+  wl_list_length(i-event_list), i-name);
else
printf(\t0, NULL,\n);
 
-- 
1.8.1.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland 1/5] doc: Insert \brief doxygen command

[Ran Benita]

On Mon, Nov 12, 2012 at 10:32:14AM -0200, Tiago Vignatti wrote:
 Signed-off-by: Tiago Vignatti tiago.vigna...@intel.com

Might be easier to just set JAVADOC_AUTOBRIED = YES in the doxygen file?
Typing '\brief' all the time can get a bit annoying.

Ran

 ---
  src/wayland-client.c |   85 
 +-
  1 file changed, 42 insertions(+), 43 deletions(-)
 
 diff --git a/src/wayland-client.c b/src/wayland-client.c
 index d3a7970..970c292 100644
 --- a/src/wayland-client.c
 +++ b/src/wayland-client.c
 @@ -138,8 +138,8 @@ wl_event_queue_release(struct wl_event_queue *queue)
   pthread_cond_destroy(queue-cond);
  }
  
 -/** Destroy an event queue
 - *
 +/**
 + * \brief Destroy an event queue
   * \param queue The event queue to be destroyed
   *
   * Destroy the given event queue. Any pending event on that queue is
 @@ -163,8 +163,8 @@ wl_event_queue_destroy(struct wl_event_queue *queue)
   pthread_mutex_unlock(display-mutex);
  }
  
 -/** Create a new event queue for this display
 - *
 +/**
 + * \brief Create a new event queue for this display
   * \param display The display context object
   * \return A new event queue associated with this display or NULL on
   * failure.
 @@ -189,8 +189,8 @@ wl_display_create_queue(struct wl_display *display)
   return queue;
  }
  
 -/** Create a proxy object with a given interface
 - *
 +/**
 + * \brief Create a proxy object with a given interface
   * \param factory Factory proxy object
   * \param interface Interface the proxy object should use
   * \return A newly allocated proxy object or NULL on failure
 @@ -258,8 +258,8 @@ wl_proxy_create_for_id(struct wl_proxy *factory,
   return proxy;
  }
  
 -/** Destroy a proxy object
 - *
 +/**
 + * \brief Destroy a proxy object
   * \param proxy The proxy to be destroyed
   *
   * \memberof wl_proxy
 @@ -290,8 +290,8 @@ wl_proxy_destroy(struct wl_proxy *proxy)
   pthread_mutex_unlock(display-mutex);
  }
  
 -/** Set a proxy's listener
 - *
 +/**
 + * \brief Set a proxy's listener
   * \param proxy The proxy object
   * \param implementation The listener to be added to proxy
   * \param data User data to be associated with the proxy
 @@ -322,8 +322,8 @@ wl_proxy_add_listener(struct wl_proxy *proxy,
   return 0;
  }
  
 -/** Prepare a request to be sent to the compositor
 - *
 +/**
 + * \brief Prepare a request to be sent to the compositor
   * \param proxy The proxy object
   * \param opcode Opcode of the request to be sent
   * \param ... Extra arguments for the given request
 @@ -484,8 +484,8 @@ connect_to_socket(const char *name)
   return fd;
  }
  
 -/** Connect to Wayland display on an already open fd
 - *
 +/**
 + * \brief Connect to Wayland display on an already open fd
   * \param fd The fd to use for the connection
   * \return A \ref wl_display object or \c NULL on failure
   *
 @@ -543,8 +543,8 @@ wl_display_connect_to_fd(int fd)
   return display;
  }
  
 -/** Connect to a Wayland display
 - *
 +/**
 + * \brief Connect to a Wayland display
   * \param name Name of the Wayland display to connect to
   * \return A \ref wl_display object or \c NULL on failure
   *
 @@ -579,8 +579,8 @@ wl_display_connect(const char *name)
   return wl_display_connect_to_fd(fd);
  }
  
 -/** Close a connection to a Wayland display
 - *
 +/**
 + * \brief Close a connection to a Wayland display
   * \param display The display context object
   *
   * Close the connection to \c display and free all resources associated
 @@ -601,8 +601,8 @@ wl_display_disconnect(struct wl_display *display)
   free(display);
  }
  
 -/** Get a display context's file descriptor
 - *
 +/**
 + * \brief Get a display context's file descriptor
   * \param display The display context object
   * \return Display object file descriptor
   *
 @@ -630,8 +630,8 @@ static const struct wl_callback_listener sync_listener = {
   sync_callback
  };
  
 -/** Block until all pending request are processed by the server
 - *
 +/**
 + * \brief Block until all pending request are processed by the server
   * \param display The display context object
   * \return The number of dispatched events on success or -1 on failure
   *
 @@ -903,8 +903,8 @@ err_unlock:
   return -1;
  }
  
 -/** Dispatch events in an event queue
 - *
 +/**
 + * \brief Dispatch events in an event queue
   * \param display The display context object
   * \param queue The event queue to dispatch
   * \return The number of dispatched events on success or -1 on failure
 @@ -926,8 +926,8 @@ wl_display_dispatch_queue(struct wl_display *display,
   return dispatch_queue(display, queue, 1);
  }
  
 -/** Process incoming events
 - *
 +/**
 + * \brief Process incoming events
   * \param display The display context object
   * \return The number of dispatched events on success or -1 on failure
   *
 @@ -956,8 +956,8 @@ wl_display_dispatch(struct wl_display *display)
   return dispatch_queue(display, display-queue, 1);
  }
  
 

[PATCH weston 1/3] compositor-x11: free or discard XCB generic_error's

[Ran Benita]

Where we don't look at the error details, pass NULL to the 'error'
argument and test using the reply return value instead.
Where we do need it, remember to free it.

Signed-off-by: Ran Benita ran...@gmail.com
---
 src/compositor-x11.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index c654aec..c69b8f6 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -115,7 +115,6 @@ x11_compositor_get_keymap(struct x11_compositor *c)
 {
xcb_get_property_cookie_t cookie;
xcb_get_property_reply_t *reply;
-   xcb_generic_error_t *error;
struct xkb_rule_names names;
struct xkb_keymap *ret;
const char *value_all, *value_part;
@@ -125,7 +124,7 @@ x11_compositor_get_keymap(struct x11_compositor *c)
 
cookie = xcb_get_property(c-conn, 0, c-screen-root,
  c-atom.xkb_names, c-atom.string, 0, 1024);
-   reply = xcb_get_property_reply(c-conn, cookie, error);
+   reply = xcb_get_property_reply(c-conn, cookie, NULL);
if (reply == NULL)
return NULL;
 
@@ -217,6 +216,7 @@ x11_compositor_setup_xkb(struct x11_compositor *c)
error = xcb_request_check(c-conn, select);
if (error) {
weston_log(error: failed to select for XKB state events\n);
+   free(error);
return;
}
 
@@ -227,19 +227,18 @@ x11_compositor_setup_xkb(struct x11_compositor *c)
   0,
   0,
   0);
-   pcf_reply = xcb_xkb_per_client_flags_reply(c-conn, pcf, error);
-   free(pcf_reply);
-   if (error) {
+   pcf_reply = xcb_xkb_per_client_flags_reply(c-conn, pcf, NULL);
+   if (!pcf_reply) {
weston_log(failed to set XKB per-client flags, not using 
   detectable repeat\n);
return;
}
+   free(pcf_reply);
 
state = xcb_xkb_get_state(c-conn, XCB_XKB_ID_USE_CORE_KBD);
-   state_reply = xcb_xkb_get_state_reply(c-conn, state, error);
-   if (error) {
+   state_reply = xcb_xkb_get_state_reply(c-conn, state, NULL);
+   if (!state_reply) {
weston_log(failed to get initial XKB state\n);
-   free(state_reply);
return;
}
 
-- 
1.8.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 2/3 v2] compositor-x11: properly initialize XKB extension

[Ran Benita]

In order to use XKB capabilities (as we do), the client must issue an
XkbUseExtension request:
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Initializing_the_X_Keyboard_Extension

The reason this succeeds currently is that XOpenDisplay from Xlib does
this for us. But it is better not to rely on that, but do it explicitly
in XCB with the rest of the XKB init sequence.

Signed-off-by: Ran Benita ran...@gmail.com
---
 src/compositor-x11.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index c69b8f6..001dec4 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -190,6 +190,8 @@ x11_compositor_setup_xkb(struct x11_compositor *c)
const xcb_query_extension_reply_t *ext;
xcb_generic_error_t *error;
xcb_void_cookie_t select;
+   xcb_xkb_use_extension_cookie_t use_ext;
+   xcb_xkb_use_extension_reply_t *use_ext_reply;
xcb_xkb_per_client_flags_cookie_t pcf;
xcb_xkb_per_client_flags_reply_t *pcf_reply;
xcb_xkb_get_state_cookie_t state;
@@ -220,6 +222,25 @@ x11_compositor_setup_xkb(struct x11_compositor *c)
return;
}
 
+   use_ext = xcb_xkb_use_extension(c-conn,
+   XCB_XKB_MAJOR_VERSION,
+   XCB_XKB_MINOR_VERSION);
+   use_ext_reply = xcb_xkb_use_extension_reply(c-conn, use_ext, NULL);
+   if (!use_ext_reply) {
+   weston_log(couldn't start using XKB extension\n);
+   return;
+   }
+
+   if (!use_ext_reply-supported) {
+   weston_log(XKB extension version on the server is too old 
+  (want %d.%d, has %d.%d)\n,
+  XCB_XKB_MAJOR_VERSION, XCB_XKB_MINOR_VERSION,
+  use_ext_reply-serverMajor, 
use_ext_reply-serverMinor);
+   free(use_ext_reply);
+   return;
+   }
+   free(use_ext_reply);
+
pcf = xcb_xkb_per_client_flags(c-conn,
   XCB_XKB_ID_USE_CORE_KBD,
   
XCB_XKB_PER_CLIENT_FLAG_DETECTABLE_AUTO_REPEAT,
-- 
1.8.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 3/3] compositor-x11: verify that detectable repeat was really set

[Ran Benita]

Since the XKB says that support for detectable repeat is in fact
optional:
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Querying_and_Changing_Per_Client_Flags
we might as well be good citizens and check that it was really set. With
the X server this would never happen, though.

Signed-off-by: Ran Benita ran...@gmail.com
---
 src/compositor-x11.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index 001dec4..c575f25 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -249,9 +249,11 @@ x11_compositor_setup_xkb(struct x11_compositor *c)
   0,
   0);
pcf_reply = xcb_xkb_per_client_flags_reply(c-conn, pcf, NULL);
-   if (!pcf_reply) {
+   if (!pcf_reply ||
+   !(pcf_reply-value  
XCB_XKB_PER_CLIENT_FLAG_DETECTABLE_AUTO_REPEAT)) {
weston_log(failed to set XKB per-client flags, not using 
   detectable repeat\n);
+   free(pcf_reply);
return;
}
free(pcf_reply);
-- 
1.8.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 1/2] compositor-x11: use _checked() with xkb_select_events to test for error

[Ran Benita]

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).

Signed-off-by: Ran Benita ran...@gmail.com
---
 src/compositor-x11.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index 71287e0..c654aec 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -206,14 +206,14 @@ x11_compositor_setup_xkb(struct x11_compositor *c)
}
c-xkb_event_base = ext-first_event;
 
-   select = xcb_xkb_select_events(c-conn,
-  XCB_XKB_ID_USE_CORE_KBD,
-  XCB_XKB_EVENT_TYPE_STATE_NOTIFY,
-  0,
-  XCB_XKB_EVENT_TYPE_STATE_NOTIFY,
-  0,
-  0,
-  NULL);
+   select = xcb_xkb_select_events_checked(c-conn,
+  XCB_XKB_ID_USE_CORE_KBD,
+  XCB_XKB_EVENT_TYPE_STATE_NOTIFY,
+  0,
+  XCB_XKB_EVENT_TYPE_STATE_NOTIFY,
+  0,
+  0,
+  NULL);
error = xcb_request_check(c-conn, select);
if (error) {
weston_log(error: failed to select for XKB state events\n);
-- 
1.8.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 2/2] compositor-x11: properly initialize XKB extension

[Ran Benita]

In order to use XKB capabilities (as we do), the client must issue an
XkbUseExtension request:
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Initializing_the_X_Keyboard_Extension

The reason this succeeds currently is that XOpenDisplay from Xlib does
this for us. But it is better not to rely on that, but do it explicitly
in XCB with the rest of the XKB init sequence.

Signed-off-by: Ran Benita ran...@gmail.com
---
 src/compositor-x11.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index c654aec..77e8600 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -191,6 +191,8 @@ x11_compositor_setup_xkb(struct x11_compositor *c)
const xcb_query_extension_reply_t *ext;
xcb_generic_error_t *error;
xcb_void_cookie_t select;
+   xcb_xkb_use_extension_cookie_t use_ext;
+   xcb_xkb_use_extension_reply_t *use_ext_reply;
xcb_xkb_per_client_flags_cookie_t pcf;
xcb_xkb_per_client_flags_reply_t *pcf_reply;
xcb_xkb_get_state_cookie_t state;
@@ -220,6 +222,24 @@ x11_compositor_setup_xkb(struct x11_compositor *c)
return;
}
 
+   use_ext = xcb_xkb_use_extension(c-conn,
+   XCB_XKB_MAJOR_VERSION,
+   XCB_XKB_MINOR_VERSION);
+   use_ext_reply = xcb_xkb_use_extension_reply(c-conn, use_ext, error);
+   if (!use_ext_reply || error) {
+   weston_log(couldn't start using XKB extension (error code %d)\n,
+  error-error_code);
+   return;
+   }
+
+   if (!use_ext_reply-supported) {
+   weston_log(XKB extension version on the server is too old 
+  (want %d.%d, has %d.%d)\n,
+  XCB_XKB_MAJOR_VERSION, XCB_XKB_MINOR_VERSION,
+  use_ext_reply-serverMajor, use_ext_reply-serverMinor);
+   return;
+   }
+
pcf = xcb_xkb_per_client_flags(c-conn,
   XCB_XKB_ID_USE_CORE_KBD,
   
XCB_XKB_PER_CLIENT_FLAG_DETECTABLE_AUTO_REPEAT,
-- 
1.8.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Use a library symbol version map

[Ran Benita]

On Thu, Oct 25, 2012 at 04:02:49PM +0200, Jan Engelhardt wrote:
 This helps package managers recognize when a new version of libxkbcommon
 (with same SONAME) is required due to new symbols.

This seems like a good thing to me. But you left out the symbols in
src/compat.c, which provides some ABI backwards compatibility. But since
xkbcommon-compat.h does the rewriting to the new symbols, and the new
release broke API and ABI anyway, I say we should just drop this file.
So if Daniel agrees, we should just remove src/compat.c, before merging
this patch.

And we should also really set --version-info... But that's a different
story.

[One comment below]

 Signed-off-by: Jan Engelhardt jeng...@inai.de
 ---
  Makefile.am  |4 +++-
  libxkbcommon.map |   66 
 ++
  2 files changed, 69 insertions(+), 1 deletion(-)
  create mode 100644 libxkbcommon.map
 
 diff --git a/Makefile.am b/Makefile.am
 index c08bca1..a50422b 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -35,7 +35,9 @@ xkbcommoninclude_HEADERS = \
   xkbcommon/xkbcommon-names.h
  
  lib_LTLIBRARIES = libxkbcommon.la
 -libxkbcommon_la_LDFLAGS = -no-undefined
 +libxkbcommon_la_LDFLAGS = \
 + -Wl,--version-script=${srcdir}/libxkbcommon.map \
 + -no-undefined

Would you mind adding -Wl,--no-undefined-version here, also? It checks
the case where you remove a symbol from the code, but not from the
version map (which of course shouldn't happen, but still).

If there's also a way to make it warn about new symbols which are
XKB_EXPORT'ed but are not mentioned in the map, that would be helpful
as well.

Thanks,
Ran

  libxkbcommon_la_SOURCES = \
   src/xkbcomp/action.c \
   src/xkbcomp/action.h \
 diff --git a/libxkbcommon.map b/libxkbcommon.map
 new file mode 100644
 index 000..822d985
 --- /dev/null
 +++ b/libxkbcommon.map
 @@ -0,0 +1,66 @@
 +XKBCOMMON_0.2.0 {
 +global:
 + xkb_keysym_get_name;
 + xkb_keysym_from_name;
 + xkb_keysym_to_utf8;
 + xkb_keysym_to_utf32;
 + xkb_context_new;
 + xkb_context_ref;
 + xkb_context_unref;
 + xkb_context_set_user_data;
 + xkb_context_get_user_data;
 + xkb_context_include_path_append;
 + xkb_context_include_path_append_default;
 + xkb_context_include_path_reset_defaults;
 + xkb_context_include_path_clear;
 + xkb_context_num_include_paths;
 + xkb_context_include_path_get;
 + xkb_context_set_log_level;
 + xkb_context_get_log_level;
 + xkb_context_set_log_verbosity;
 + xkb_context_get_log_verbosity;
 + xkb_context_set_log_fn;
 + xkb_keymap_new_from_names;
 + xkb_keymap_new_from_file;
 + xkb_keymap_new_from_string;
 + xkb_keymap_ref;
 + xkb_keymap_unref;
 + xkb_keymap_get_as_string;
 + xkb_keymap_num_mods;
 + xkb_keymap_mod_get_name;
 + xkb_keymap_mod_get_index;
 + xkb_keymap_num_layouts;
 + xkb_keymap_layout_get_name;
 + xkb_keymap_layout_get_index;
 + xkb_keymap_num_layouts_for_key;
 + xkb_keymap_num_levels_for_key;
 + xkb_keymap_key_get_syms_by_level;
 + xkb_keymap_num_leds;
 + xkb_keymap_led_get_name;
 + xkb_keymap_led_get_index;
 + xkb_keymap_key_repeats;
 + xkb_state_new;
 + xkb_state_ref;
 + xkb_state_unref;
 + xkb_state_get_keymap;
 + xkb_state_update_key;
 + xkb_state_key_get_syms;
 + xkb_state_key_get_one_sym;
 + xkb_state_key_get_layout;
 + xkb_state_key_get_level;
 + xkb_state_update_mask;
 + xkb_state_serialize_mods;
 + xkb_state_serialize_layout;
 + xkb_state_mod_name_is_active;
 + xkb_state_mod_names_are_active;
 + xkb_state_mod_index_is_active;
 + xkb_state_mod_indices_are_active;
 + xkb_state_mod_index_is_consumed;
 + xkb_state_mod_mask_remove_consumed;
 + xkb_state_layout_name_is_active;
 + xkb_state_layout_index_is_active;
 + xkb_state_led_name_is_active;
 + xkb_state_led_index_is_active;
 +local:
 + *;
 +};
 -- 
 1.7.10.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libxkbcommon v4 2/2] Add xkb_keysym_from_casename() helper for case-insensitive search

[Ran Benita]

On Sun, Oct 07, 2012 at 03:59:09PM +0200, David Herrmann wrote:
 This adds another helper that allows finding a keysym based on a
 case-insensitive search. This should really be supported as many keysyms
 have really weird capitalization-rules.
 
 However, as this may produce conflicts, users must be warned to only use
 this for fallback paths or error-recovery. This is also the reason why the
 internal XKB parsers still use the case-sensitive search.
 
 This also adds some test-cases so the expected results are really
 produced.
 
 Signed-off-by: David Herrmann dh.herrm...@googlemail.com
 ---
 Ran, could you check whether the new binary-size is acceptable? I get about 
 350K
 for the new search-arrays.
 
 Regards
 David

Hi David,
The patch looks good to me, thanks for going through all of these
revisions! The first patch is an improvement regardless of the feature,
and the second is nice to have IMO.

A couple of comments below.

 
  makekeys.py   |  6 
  src/keysym.c  | 94 
 +++
  test/keysym.c | 29 
  xkbcommon/xkbcommon.h | 15 
  4 files changed, 144 insertions(+)
 
 diff --git a/makekeys.py b/makekeys.py
 index 94885c0..ab75cce 100644
 --- a/makekeys.py
 +++ b/makekeys.py
 @@ -5,6 +5,7 @@ import re, sys, itertools
  pattern = 
 re.compile(r'^#define\s+XKB_KEY_(?Pname\w+)\s+(?Pvalue0x[0-9a-fA-F]+)\s')
  matches = [pattern.match(line) for line in open(sys.argv[1])]
  entries = [(m.group(name), int(m.group(value), 16)) for m in matches if 
 m]
 +lentries = [(m.group(name).lower(), m.group(name)) for m in matches if m]
  
  print('''struct name_keysym {
  const char *name;
 @@ -16,6 +17,11 @@ for (name, _) in sorted(entries, key=lambda e: e[0]):
  print('{{ {name}, XKB_KEY_{name} }},'.format(name=name))
  print('};\n')
  
 +print('static const struct name_keysym case_to_keysym[] = {');
 +for (lname, name) in sorted(lentries, key=lambda e: e[0]):
 +print('{{ {lname}, XKB_KEY_{name} }},'.format(lname=lname, 
 name=name))
 +print('};\n')

I think it would be more space efficient if we don't use a new 'lentries'
list like above, but reuse the (original-cased) 'entries' list and
change the sort key from 'lambda e: e[0]' to 'lambda e: e[0].lower()'.
This will result in a table with the same strings being generated but
ordered by lowercase. If I'm reading your code correctly, it would work
nonetheless, but any half-decent compiler/linker would only store the
strings once, e.g. instead of this:
$ strings libxkbcommon.so | grep -i lambda
Greek_LAMBDA
Greek_lambda
greek_lambda
You get this:
$ strings libxkbcommon.so | grep -i lambda
Greek_LAMBDA
Greek_lambda

Also maybe we want to stick a:
locale.setlocle(locale.LC_ALL, C)
or en_us.UTF-8 there? I don't know if the python2/3 functions are
locale sensitive, but why not to be safe I guess.

 +
  # *.sort() is stable so we always get the first keysym for duplicate
  print('static const struct name_keysym keysym_to_name[] = {');
  for (name, _) in (next(g[1]) for g in itertools.groupby(sorted(entries, 
 key=lambda e: e[1]), key=lambda e: e[1])):
 diff --git a/src/keysym.c b/src/keysym.c
 index 85d4386..d320055 100644
 --- a/src/keysym.c
 +++ b/src/keysym.c
 @@ -65,6 +65,12 @@ static int compare_by_name(const void *a, const void *b)
  return strcmp(key-name, entry-name);
  }
  
 +static int compare_by_casename(const void *a, const void *b)
 +{
 +const struct name_keysym *key = a, *entry = b;
 +return strcasecmp(key-name, entry-name);
 +}
 +
  XKB_EXPORT int
  xkb_keysym_get_name(xkb_keysym_t ks, char *buffer, size_t size)
  {
 @@ -144,6 +150,94 @@ xkb_keysym_from_name(const char *s)
  return XKB_KEY_NoSymbol;
  }
  
 +/*
 + * Find the lower-case keysym of any keysym entry.
 + * If we use bsearch() to find a keysym based on a case-insensitive search, 
 we
 + * may get _any_ of all possible duplicates back. This function looks at all
 + * entries before and after @entry which have the same name (case 
 insensitive)
 + * and then returns the _best_ match of all.
 + * The _best_ match is the lower-case keysym which we find with the help of
 + * xkb_keysym_is_lower().
 + */
 +static const struct name_keysym *find_lcase(const struct name_keysym *entry)
 +{
 +const struct name_keysym *iter, *last;
 +size_t len = sizeof(case_to_keysym) / sizeof(*case_to_keysym);
 +
 +if (xkb_keysym_is_lower(entry-keysym))
 +return entry;

xkb_keysym_is_lower is pretty lousy right now, it doesn't handle unicode
keysysm at all. But I will fix this later (I think we're going to have
to copy XConvertCase and UCSConvertCase from libX11:src/KeyBind.c - kind
of ugly).

Thanks,
Ran

 +
 +for (iter = entry - 1; iter = case_to_keysym; --iter) {
 +if (strcasecmp(iter-name, entry-name))
 +break;
 +if (xkb_keysym_is_lower(iter-keysym))
 +return iter;
 +}
 +
 +last = 

Re: [PATCH libxkbcommon v2 1/2] makekeys: use GNU gperf to generate perfect hashtables

[Ran Benita]

On Thu, Oct 04, 2012 at 04:58:50PM +0200, David Herrmann wrote:
 Hi Ran
 
 On Wed, Oct 3, 2012 at 10:18 AM, Ran Benita ran...@gmail.com wrote:
 
 [snip]
 
  So since makekeys is ugly and gperf is a bit excessive, maybe we should
  just keep it simple, what do you think?
 
 Indeed. Thanks a lot for reviewing though. Just some comments on your
 patch below:
 
  From 8fb5efb045b7207b010c979cbeae8f8222759961 Mon Sep 17 00:00:00 2001
  From: Ran Benita ran...@gmail.com
  Date: Wed, 3 Oct 2012 10:09:48 +0200
  Subject: [PATCH libxkbcommon] Replace makekeys with python script + binary
   search
 
 Great empty commit-message ;) Maybe mention that we used to have a
 home-brew hash-table (old makekeys) and gperf is not worth it as it
 generates huge tables. So we just go with bsearch here. If anyone
 wants to change that, they should provide proper benchmarks first.

Oh, I didn't intend it to be merged, it was just to test the concept. I
was actually hoping you would write it properly :)
Also I think there might be a bug in the python script I did, unless
sorted() always keeps entries with the same keys in their original
order.

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libxkbcommon v2 1/2] makekeys: use GNU gperf to generate perfect hashtables

[Ran Benita]

Hi David,

On Tue, Oct 02, 2012 at 07:51:53PM +0200, David Herrmann wrote:
 Instead of using a home-brew hashtable generator, we should instead use
 the gperf program which is known to work.
 
 This removes the makekeys programs and instead replaces it by a file
 that can generate input files for gperf. Gperf then generates hashtables
 for all of these input files and writes them concatenated into
 ks_tables.h which then can be used from keysym.c
 
 Unfortunately, gperf does not support integer keys but only strings or
 binary data. Therefore, we have to make the keysym-name lookup
 little-endian to avoid errors during cross compilation.
 
 Signed-off-by: David Herrmann dh.herrm...@googlemail.com
 ---

The code is really nice, I have no comments on it.

I noticed though that it really blows up our binary size. Here's size -A
(only the relevant sections, CFLAGS=-O2) of current master:

sectionsize addr
.text11070810608
.rodata   95684   121344
.data.rel.ro   2192   237728
Total238568

Here it is after adding the third table to old makekeys, in the v1 patch
you sent:

sectionsize addr
.text11072410608
.rodata  122340   121376
.data.rel.ro   2192   264416
Total265240

And here it is with these patches:

sectionsize addr
.text11278828912
.rodata  716478   141728
.data.rel.ro  55824   879136
Total933614

So gperf is clearly doing... something here. In the gperf manual they
mention:
The size of the generate static keyword array can get extremely large
if the input keyword file is large or if the keywords are quite
similar. This tends to slow down the compilation of the generated C
code, and greatly inflates the object code size. If this situation
occurs, consider using the ‘-S’ option to reduce data size, potentially
increasing keyword recognition time a negligible amount. Since many C
compilers cannot correctly generate code for large switch statements it
is important to qualify the -S option with an appropriate numerical
argument that controls the number of switch statements generated.

To reduce the size I tried removing %compare-length from the name-to-key
tables (which helped a bit). Also tried using a few %switch numbers (and
thus let gcc create the lookup tables on its own), which reduced it to
about 55, but then the compilation takes about a minute :)

So to be honest, the hashing that gperf and makekeys do is nice, but I
don't see why we do it anyway, if it complicates thing. For example, I
just took 15 minutes to do it in the obvious way of creating simple
sorted {name, keysym} arrays and doing binary search on them, to replace
the current makekeys code (see attached patch - just a proof of concept
hacked up python script and a couple bsearch's). I don't see any
performance issues, and the size is:

.text11051648016
.rodata   66366   158560
.data.rel.ro  39568   241696
Total283860

With adding the third table it is:

.text11054867184
.rodata   80278   177760
.data.rel.ro  58768   278752
Total336180

So since makekeys is ugly and gperf is a bit excessive, maybe we should
just keep it simple, what do you think?

Ran
From 8fb5efb045b7207b010c979cbeae8f8222759961 Mon Sep 17 00:00:00 2001
From: Ran Benita ran...@gmail.com
Date: Wed, 3 Oct 2012 10:09:48 +0200
Subject: [PATCH libxkbcommon] Replace makekeys with python script + binary
 search

Signed-off-by: Ran Benita ran...@gmail.com
---
 Makefile.am  |   9 +-
 configure.ac |  14 +--
 makekeys.py  |  23 
 makekeys/.gitignore  |   1 -
 makekeys/Makefile.am |  10 --
 makekeys/makekeys.c  | 302 ---
 src/keysym.c |  97 ++---
 7 files changed, 62 insertions(+), 394 deletions(-)
 create mode 100644 makekeys.py
 delete mode 100644 makekeys/.gitignore
 delete mode 100644 makekeys/Makefile.am
 delete mode 100644 makekeys/makekeys.c

diff --git a/Makefile.am b/Makefile.am
index 26646fb..dfbd8d9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,7 +1,5 @@
 ACLOCAL_AMFLAGS = -I m4
 
-SUBDIRS = makekeys
-
 pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA = xkbcommon.pc
 
@@ -92,11 +90,8 @@ src/xkbcomp/parser.c: $(top_builddir)/src/$(am__dirstamp) 
$(top_builddir)/src/xk
 src/xkbcomp/parser.h: $(top_builddir)/src/$(am__dirstamp) 
$(top_builddir)/src/xkbcomp/$(am__dirstamp)
 src/xkbcomp/scanner.c: $(top_builddir)/src/$(am__dirstamp) 
$(top_builddir)/src/xkbcomp/$(am__dirstamp)
 
-src/ks_tables.h: $(top_builddir)/makekeys/makekeys$(EXEEXT)
-   $(AM_V_GEN)$(top_builddir)/makekeys/makekeys 
$(top_srcdir)/xkbcommon/xkbcommon-keysyms.h  $@
-
-$(top_builddir)/makekeys/makekeys$(EXEEXT): $(top_srcdir

Re: [PATCH libxkbcommon 1/2] makekeys: add all symbols converted to lower-case

[Ran Benita]

Hi David,

On Mon, Oct 01, 2012 at 07:29:58PM +0200, David Herrmann wrote:
 xkb_keysym_from_name() uses a big lookup table generated by makekeys
 to find keysyms. It does this case-sensitive because we have keys like
 XKB_KEY_A and XKB_KEY_a. So if a user searches for a we must always
 return the case-sensitive match, which is XKB_KEY_a.
 However, lets look at XKB_KEY_XF86HomePage. The user currently _must_
 enter XF86HomePage correctly to get this keysym. If they enter
 Xf86HomePage or XF86Homepage or anything else, xkb_keysym_from_name()
 will fail. This is unreasonable and bogus. Instead we should allow an
 application to have a case-insensitive search as fallback. This removes
 policy from xkbcommon and moves it into the application. They can now
 decide, whether they use a possibly unsafe fallback or stay with the
 case-sensitive search.
 
 Therefore, this patch modifies makekeys to convert all symbols to
 lower-case and add them into the lookup table, too. The case-sensitive
 symbols are unchanged and stay in the table, but a user-application can
 now fall back to lower-case search if a symbol cannot be resolved.
 
 This patch does take care that any case-sensitive key overwrites any
 lower-case key. That is, if makekeys adds XKB_KEY_A, it will add it as
 A and a. If XKB_KEY_a is added later, it will overwrite the previous
 a because this is a case-sensitive match.
 This guarantees that looking up for a always returns KEY_a.
 
 This patch also makes sure that case-sensitive keys are inserted into the
 lookup table first. This guarantees that xkb_keysym_get_name() always
 returns the first match which is the case-sensitive entry.
 
 There are several theoretical pitfalls here:
  - Assume there is a key Abcd and abcd. If the user searches for ABCD and
does not find anything, the fallback will return abcd, although The
user might have preferred Abcd.
An application can circumwent it by simply not using the fallback
lower-case search, so this does not affect existing applications.
  - Assume there is a key AbCd but no other key abcd in any case. If the
user searches for abcd, it will return AbCd even though they didn't
request a case-insensitive match. This _does_ affect existing
applications.
However, there is currently no key where a user wouldn't be happy about
this, because every key where case really changes semantics, is always
available in both, upper-case and lower-case and so this doesn't
happen.
An application can catch this by converting the result back to a name
and checking whether the names match. However, I really don't know why
anyone would bother?
 
 I haven't found any other cases where this changes semantics. There are
 some pitfalls when doing the case-insensitive fallback match, however,
 this is optional!
 The only case were existing application's behavior changes are listed
 above. However, considering that nearly everyone wants lower-case keys,
 anyway, this is in my eyes the best solution.
 
 Furthermore, new keysyms should be avoided and users should use Unicode
 symbols to identify keys. This is always unambigious and isn't affected at
 all by this patch.
 
 Signed-off-by: David Herrmann dh.herrm...@googlemail.com
 ---
  makekeys/makekeys.c | 71 
 ++---
  1 file changed, 67 insertions(+), 4 deletions(-)

I like the idea, and it seems to work.

First, one thing that's easy to miss, this should work:
assert(test_string(xf86_switch_vt_5, XKB_KEY_XF86Switch_VT_5));
Have a look at src/keysym.c, it treats the XF86_ case specially.

Second, I think that in the keymap files themselves (xkb_symbols etc.)
we should always do case-sensitive lookup, this would otherwise lead to
ambiguity, and the original xkbcomp won't be able to parse these files,
for no particularly good reason. So LookupKeysym() in xkbcomp/symbols.c
needs to adapt as well, e.g. by comparing to keysym_get_name. If it can
be made more efficient such that it doesn't need the extra lookup +
compare, that's even better.

Also, this probably warrants a note in the xkb_keysym_from_name()
documentation, explaining how to use it for a case-sensitive and
case-insesitive lookup. I actually think that adding a flag to control
this would be best (which would break ABI/API if done directly), but
don't mind much.

Finally, some minor comments below.

 diff --git a/makekeys/makekeys.c b/makekeys/makekeys.c
 index 62d7255..b48e889 100644
 --- a/makekeys/makekeys.c
 +++ b/makekeys/makekeys.c
 @@ -33,6 +33,7 @@
  
  #include xkbcommon/xkbcommon.h
  
 +#include ctype.h
  #include inttypes.h
  #include stdio.h
  #include stdlib.h
 @@ -40,7 +41,7 @@
  
  typedef uint32_t Signature;
  
 -#define KTNUM 4000
 +#define KTNUM (4000 * 2)
  
  static struct info {
  char*name;
 @@ -115,19 +116,81 @@ main(int argc, char *argv[])
  continue;
  }
  
 +/* Every key is added to the list 

Re: Will Wayland also ship with broken keyboard layout switching?

[Ran Benita]

On Tue, Oct 02, 2012 at 12:35:31PM +1000, Daniel Stone wrote:
 Hi,
 
 On 2 October 2012 11:38,  dar...@chaosreigns.com 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 weston uses, so it seems likely to not have this problem.
 
  Wayland is a protocol, and I think it's appropriate to say keyboard input
  implementation is not specified by it, so another implementation could do
  it a different way.  Weston is just the reference implementation.  But I
  think others are expected to use xkbcommon.
 
 Yeah, xkbcommon doesn't have this problem at all.  It's mostly just an
 implementation detail of the X server, that we're completely free from
 because we always send our keymaps losslessly serialised to strings,
 rather than a broken binary format.

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?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libxkbcommon 1/2] makekeys: add all symbols converted to lower-case

[Ran Benita]

On Tue, Oct 02, 2012 at 11:07:11AM +0200, David Herrmann wrote:
 On Tue, Oct 2, 2012 at 9:37 AM, Ran Benita ran...@gmail.com wrote:
  I like the idea, and it seems to work.
 
  First, one thing that's easy to miss, this should work:
  assert(test_string(xf86_switch_vt_5, XKB_KEY_XF86Switch_VT_5));
  Have a look at src/keysym.c, it treats the XF86_ case specially.
 
 Argh, I overlooked that. Anyway, that's as easy as trying xf86, too.
 I will add it.
 
  Second, I think that in the keymap files themselves (xkb_symbols etc.)
  we should always do case-sensitive lookup, this would otherwise lead to
  ambiguity, and the original xkbcomp won't be able to parse these files,
  for no particularly good reason. So LookupKeysym() in xkbcomp/symbols.c
  needs to adapt as well, e.g. by comparing to keysym_get_name. If it can
  be made more efficient such that it doesn't need the extra lookup +
  compare, that's even better.
 
 That was my main concern, too. The current approach just makes any
 lower-case lookup succeed. So I was wondering whether converting this
 whole mess to gperf would be acceptable? I would then create two
 tables, a case-sensitive and a lower-case table.
 We can then decide, whether we add a flag to xkb_keysym_from_name() or
 whether we introduce a separate xkb_keysym_from_casename() or
 something like that (adj. strcasecmp()).
 
 This would preserve the semantics of xkb_keysym_from_name(), which is
 probably what we want(?).

Yes, that sounds good to me. It would be nice to get rid of makekeys.

  Also, this probably warrants a note in the xkb_keysym_from_name()
  documentation, explaining how to use it for a case-sensitive and
  case-insesitive lookup. I actually think that adding a flag to control
  this would be best (which would break ABI/API if done directly), but
  don't mind much.
 
 I prefer the flags argument, too.
 
  Finally, some minor comments below.
 
 Thanks for the code-review. But I think I might just try gperf to
 replace that unmaintainable makekeys program. Any objections?

I have used gperf successfully before, it works quite well. We could also
use it for some other stuff, later.

Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Bug regarding evdev input and compositor focus

[Ran Benita]

Hello,

I was writing some input handling code for a separate program, when I
stumbled into an issue and eventually decided to look at how wayland
does it for inspiration. Unfortunately, wayland has a similar issue ;(

The bug can be reproduced easily:
- Start compositor-drm on some VT.
- Switch to another VT.
- Watch the CPU utilization go to 100%.

In order to stop receiving input events when we VT switch out of wayland
(i.e compositor-focus = false), the function evdev_input_device_data
has a simple check:

ec = device-master-base.compositor;
if (!ec-focus)
return 1;

This check goes *before* the read(), the device fd always has data in
it, the event loop keeps dispatching it, and we get into an endless
loop until we get focus again.

I guess there are a few ways to solve it:
- Move the check after the read (not very nice).
- Remove the fd from event loop when losing focus.
- Close the fd altogether and re-open() when we get focus again.
The latter is how X does it (see hw/xfree86/common/xf86Events.c,
xf86VTSwitch()).

Thanks,
Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel