Looking for something to hack on to get started with Wayland
Hello. With the help of darxus I was able to get wayland building and running here on Kubuntu Maverick. I was looking for something to work on that would get me started in Wayland development. I'm familiar with c/c++, linux, git and open source development etc. I noticed the TODO file but nothing jumped out and I figured I might as well just ask someone to pick for me a reasonable sized thing to work on as a beginner. Chris ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] - Add the wayland-build.sh script to building.html and to the directory
Darxus' build scripts made getting, building and running wayland very
easy. It seems useful to provide these to users on the official
wayland site to lower the barrier to getting started with wayland.
I combined two of them together and split some of the functionality
out into separate commands to make it easier to update, rebuild etc. I
also added a brief mention to the top of the building.html.
Chris
From 71f876333bc37b164c8e62c3ec4ac9329ba59ffb Mon Sep 17 00:00:00 2001
From: Chris Morgan
Date: Fri, 4 Feb 2011 22:46:51 -0500
Subject: [PATCH] Add the wayland-build.sh script to building.html and to the directory
---
building.html| 13 +++
wayland-build.sh | 302 ++
2 files changed, 315 insertions(+), 0 deletions(-)
create mode 100755 wayland-build.sh
diff --git a/building.html b/building.html
index 446e780..a864e4d 100644
--- a/building.html
+++ b/building.html
@@ -21,6 +21,19 @@ below, but you can use your favorite directory of course or install
over your system copy (pass --prefix=/usr --sysconfdir=/etc,
generally).
+wayland-build.sh helper script
+A helpful script, wayland-build.sh, is available that can automate building and running Wayland. This script performs most of the steps found in the below sections.
+
+To get started put this script into a directory on your system and run:
+
+./wayland-build.sh ubuntu (if on ubuntu)
+./wayland-build.sh clone
+./wayland-build.sh configure
+./wayland-build.sh make
+./wayland-build.sh run
+
+
+
Setting up the environment
If you want to install in $HOME/install (or another location that won't
interfere with the rest of your system) you'll need to set the following
diff --git a/wayland-build.sh b/wayland-build.sh
new file mode 100755
index 000..978eeb1
--- /dev/null
+++ b/wayland-build.sh
@@ -0,0 +1,302 @@
+#!/bin/bash
+
+# This builds and installs Wayland. Also includes setup for Ubuntu Maverick
+#
+# 2010-11-20 Changes from André de Souza Pinto
+# 2010-12-06 "set -e" instead of "set -u". More aggressive git cleaning.
+# 2010-12-29 --with-xkb-config-root, WAYLAND_DEBUG,
+#gtk building stuff that doesn't work yet
+# 2011-01-03 Upstream gtk git, reset --hard
+# 2011-01-04 Conditional for building gtk instead of commenting out
+# 2011-01-07 Don't reset to origin/master, build vte, added
+#gobject-introspection package required to build vte, added
+#gperf for gtk
+# 2011-01-23 Added pixman git, new dep of cairo, stop using deprecated
+#--enable-gles-overlay
+# 2011-01-26 Install rsvg-convert for new window icon, also start:
+#eventdemo, resizor, and simple-client
+# 2011-01-31 Remove --disable-gallium-{i915,i965} from mesa build flags
+# 2011-02-04 Break steps into separate functions, add usage documentation
+
+
+build_gtk=0
+
+# Change this to where you want everything installed:
+installprefix=$HOME/wayland/install
+
+# You might want to put these in your ~/.bashrc
+PKG_CONFIG_PATH=$installprefix/lib/pkgconfig/:$installprefix/share/pkgconfig/
+export PKG_CONFIG_PATH
+ACLOCAL="aclocal -I $installprefix/share/aclocal"
+export ACLOCAL
+C_INCLUDE_PATH=$installprefix/include
+export C_INCLUDE_PATH
+LIBRARY_PATH=$installprefix/lib
+export LIBRARY_PATH
+
+# Get some more debugging output
+MESA_DEBUG=1
+export MESA_DEBUG
+EGL_LOG_LEVEL=debug
+export EGL_LOG_LEVEL
+LIBGL_DEBUG=verbose
+export LIBGL_DEBUG
+#WAYLAND_DEBUG=1
+#export WAYLAND_DEBUG
+
+XDG_RUNTIME_DIR=/tmp
+export XDG_RUNTIME_DIR
+GDK_BACKEND=wayland
+export GDK_BACKEND
+
+# Do *not* put this in your ~/.bashrc, it will break things.
+LD_LIBRARY_PATH=$installprefix/lib
+export LD_LIBRARY_PATH
+
+gitDirectories="drm mesa xproto kbproto macros libX11 libxkbcommon pixman cairo wayland"
+
+DIST=`cat /etc/lsb-release | grep '^DISTRIB_ID' | awk -F= '{ print $2 }'`
+
+function ubuntu_prerequisites()
+{
+ # Paste these one at a time because they're interactive.
+ sudo apt-get install aptitude
+ sudo aptitude install build-essential libtool libxi-dev libxmu-dev libxt-dev bison flex libgl1-mesa-dev xutils-dev libtalloc-dev libdrm-dev autoconf x11proto-kb-dev libegl1-mesa-dev libgles2-mesa-dev libgdk-pixbuf2.0-dev libudev-dev libxcb-dri2-0-dev libxcb-xfixes0-dev shtool libffi-dev libpoppler-glib-dev libgtk2.0-dev git diffstat libx11-xcb-dev quilt autopoint dh-autoreconf xkb-data gtk-doc-tools gobject-introspection gperf librsvg2-bin
+}
+
+function clone()
+{
+ # Needed for wayland on nouveau
+ git clone git://anongit.freedesktop.org/git/mesa/drm
+
+ # Needed for wayland
+ git clone git://anongit.freedesktop.org/mesa/mesa
+
+ # Needed for libxkbcommon
+ git clone git://anongit.freedesktop.org/xorg/proto/xproto
+
+ # Needed for libxkbcommon
+ git clone git://anongit.freedesktop.org/xorg/proto/kbproto
+
+ # Needed for libX11
+ git clone git://anongit.freedesktop.org/xo
[PATCH] - Map enum window_location to enum wl_shell_resize for the call to wl_shell_resize() to match the type used in shell_resize()
From dba11faf766d5abecc84c3d55799db6871ecdd44 Mon Sep 17 00:00:00 2001
From: Chris Morgan
Date: Sat, 5 Feb 2011 22:30:13 -0500
Subject: [PATCH] Map enum window_location to enum wl_shell_resize for the call to wl_shell_resize() to match the type used in shell_resize()
---
clients/window.c | 31 ++-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index da9b339..4563edf 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -147,6 +147,32 @@ enum window_location {
WINDOW_CLIENT_AREA = 18,
};
+// Map from internal window_location to wl_shell_resize opcode
+static enum wl_shell_resize MapWindowLocationToShellResize(enum window_location location)
+{
+ switch(location)
+ {
+ case WINDOW_RESIZING_TOP:
+ return WL_SHELL_RESIZE_TOP;
+ case WINDOW_RESIZING_BOTTOM:
+ return WL_SHELL_RESIZE_BOTTOM;
+ case WINDOW_RESIZING_LEFT:
+ return WL_SHELL_RESIZE_LEFT;
+ case WINDOW_RESIZING_TOP_LEFT:
+ return WL_SHELL_RESIZE_TOP_LEFT;
+ case WINDOW_RESIZING_BOTTOM_LEFT:
+ return WL_SHELL_RESIZE_BOTTOM_LEFT;
+ case WINDOW_RESIZING_RIGHT:
+ return WL_SHELL_RESIZE_RIGHT;
+ case WINDOW_RESIZING_TOP_RIGHT:
+ return WL_SHELL_RESIZE_TOP_RIGHT;
+ case WINDOW_RESIZING_BOTTOM_RIGHT:
+ return WL_SHELL_RESIZE_BOTTOM_RIGHT;
+ default:
+ return WL_SHELL_RESIZE_NONE;
+ }
+}
+
const char *option_xkb_layout = "us";
const char *option_xkb_variant = "";
const char *option_xkb_options = "";
@@ -933,10 +959,13 @@ window_handle_button(void *data,
case WINDOW_RESIZING_TOP_RIGHT:
case WINDOW_RESIZING_BOTTOM_LEFT:
case WINDOW_RESIZING_BOTTOM_RIGHT:
+ {
+ enum wl_shell_resize resizeOpcode = MapWindowLocationToShellResize(location);
wl_shell_resize(window->display->shell,
window->surface, input_device, time,
- location);
+ resizeOpcode);
break;
+ }
case WINDOW_CLIENT_AREA:
if (window->button_handler)
(*window->button_handler)(window,
--
1.7.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] - Add the wayland-build.sh script to building.html and to the directory
On Friday, February 4, 2011, Chris Morgan wrote: > Darxus' build scripts made getting, building and running wayland very > easy. It seems useful to provide these to users on the official > wayland site to lower the barrier to getting started with wayland. > > I combined two of them together and split some of the functionality > out into separate commands to make it easier to update, rebuild etc. I > also added a brief mention to the top of the building.html. > > Chris > Is this the right mailing list for patches? I didn't see a separate patches list. Chris ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Type safety of protocol calls
Hello. I ran into an issue figuring out how a resize event made it's way from window.c in the client to shell.c on the server. I think I figured out the mapping and sent a patch that performs the mapping between the two different types being used. Assuming the protocol methods specified specific types like enum wl_shell_resize vs uint32, is there some way to get gcc to warn about the implicit type conversion? It would be nice to avoid confusion about the desired type for the rpc calls. I know building with c++ would allow this. Any reason we couldn't go that route to tighten up the API? Chris ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Type safety of protocol calls
On Sunday, February 6, 2011, Kristian Høgsberg wrote: > On Sun, Feb 6, 2011 at 11:57 AM, Chris Morgan wrote: >> Hello. >> >> I ran into an issue figuring out how a resize event made it's way from >> window.c in the client to shell.c on the server. I think I figured out >> the mapping and sent a patch that performs the mapping between the two >> different types being used. > > I saw the patch, but the window.h #defines are defined to match the > protocol enumeration where they overlap for convenience. That's > perfectly legal in C, safe and convenient.. You may not like that > technique, but claiming that the protocol isn't typesafe for this > reason is a little disingenuous. > > Kristian > Hi. I thought when a function called for an enum that in c++ a warning or error was generated when passing anything other than that enum into that function? I thought that was generally considered type safety, should I have called it strict type conversion instead? I see the utility of mapping the two enums onto each other but I don't think is a good idea. Why not be strict where possible about the values passed through the protocol? What about the risk of someone changing one enum without changing the other? Wouldn't the issue be avoided if the protocol call specified the enum and a c++ compiler were used? If we can lock things down and prevent future errors why not attempt to do so? Chris ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Type safety of protocol calls
On Sunday, February 6, 2011, Corbin Simpson wrote: > C++ type safety is still compile-time-only in this case and not necessarily > more bulletproof. Even in EHLLs, I would still take the time to write out > explicit enum mapping code rather than trust the compiler. > Sending from a mobile, pardon the brevity. ~ C. EHLLs? Wouldn't c++ at least force an explcit cast, which is at least somewhat self documenting since you can see the target type? Did you happen to see my patch to explicitly map the two enums or was that not what you meant by mapping? Chris ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Type safety of protocol calls
On Feb 6, 2011, at 1:22 PM, "Kristian Høgsberg" wrote: > 2011/2/6 Chris Morgan : >> On Sunday, February 6, 2011, Kristian Høgsberg wrote: >>> On Sun, Feb 6, 2011 at 11:57 AM, Chris Morgan wrote: >>>> Hello. >>>> >>>> I ran into an issue figuring out how a resize event made it's way from >>>> window.c in the client to shell.c on the server. I think I figured out >>>> the mapping and sent a patch that performs the mapping between the two >>>> different types being used. >>> >>> I saw the patch, but the window.h #defines are defined to match the >>> protocol enumeration where they overlap for convenience. That's >>> perfectly legal in C, safe and convenient.. You may not like that >>> technique, but claiming that the protocol isn't typesafe for this >>> reason is a little disingenuous. >>> >>> Kristian >>> >> >> Hi. >> >> I thought when a function called for an enum that in c++ a warning or >> error was generated when passing anything other than that enum into >> that function? I thought that was generally considered type safety, >> should I have called it strict type conversion instead? > > You're talking about C++ and C++ type conversion. Wayland is written in C. > > Kristian Maybe we could compile the c code as c++? Wouldn't require using classes etc but would provide better type conversion checking. Chris ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Running on bare hardware
On Feb 6, 2011, at 3:17 PM, Dave Airlie wrote: >> >> (It is also a great pity that whoever designed the modesetting ioctls >> thought _u64 was a good type for all the pointer values. Whoever designed >> the original ioctls used pointer types very successfully.) > > Why would you consider yourself even remotely qualified to make such > a statement? it sounds like you are completely clueless to how ioctls > work on Linux > > because I'm feeling generous, instead of calling you names, I'll just > say 32 bit process on a 64-bit kernel. > > Maybe you should re-write your email above from a position of humility > instead of unfounded arrogance. > > Dave His email didn't seem overly arrogant to me. I'd actually be interested in more info about how the issue and the differences in opinion. No need to make the conversation into a pissing match. Chris ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] Move window frame surface dimensions into struct display and begin using them in place of hardcoded values
clients/window.c | 44 +++-
1 files changed, 35 insertions(+), 9 deletions(-)
From 202d2c7ddd3503fc9bf015375ff7344c89dfadee Mon Sep 17 00:00:00 2001
From: Chris Morgan
Date: Sun, 6 Feb 2011 23:12:45 -0500
Subject: [PATCH] Move window frame surface dimensions into struct display and begin using them in place of hardcoded values
---
clients/window.c | 44 +++-
1 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index 4563edf..446c44d 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -75,7 +75,17 @@ struct display {
struct wl_list window_list;
struct wl_list input_list;
char *device_name;
+
+ // pre-rendered fixed-size surfaces that are copied/scaled
+ // to draw the appropriate frame
cairo_surface_t *active_frame, *inactive_frame, *shadow;
+
+ // width and height in pixels of the active, inactive and shadow surfaces
+ int frameWidth, frameHeight;
+
+ // width of the frame region of the window
+ int borderWidth;
+
struct xkb_desc *xkb;
cairo_surface_t **pointer_surfaces;
@@ -755,8 +765,8 @@ window_draw_decorations(struct window *window)
cairo_set_source_rgba(cr, 0, 0, 0, 0.6);
tile_mask(cr, window->display->shadow,
shadow_dx, shadow_dy, width, height,
- window->margin + 10 - shadow_dx,
- window->margin + 10 - shadow_dy);
+ window->margin + window->display->borderWidth - shadow_dx,
+ window->margin + window->display->borderWidth - shadow_dy);
if (window->keyboard_device)
frame = window->display->active_frame;
@@ -764,7 +774,7 @@ window_draw_decorations(struct window *window)
frame = window->display->inactive_frame;
tile_source(cr, frame, 0, 0, width, height,
- window->margin + 10, window->margin + 50);
+ window->margin + window->display->borderWidth, window->margin + 50);
cairo_set_operator(cr, CAIRO_OPERATOR_OVER);
cairo_set_font_size(cr, 14);
@@ -1591,30 +1601,46 @@ display_render_frame(struct display *d)
int radius = 8;
cairo_t *cr;
- d->shadow = cairo_image_surface_create (CAIRO_FORMAT_ARGB32, 128, 128);
+ d->frameWidth = 128;
+ d->frameHeight = 128;
+ d->borderWidth = 10;
+
+ d->shadow = cairo_image_surface_create (CAIRO_FORMAT_ARGB32,
+ d->frameWidth, d->frameHeight);
cr = cairo_create(d->shadow);
cairo_set_operator(cr, CAIRO_OPERATOR_OVER);
cairo_set_source_rgba(cr, 0, 0, 0, 1);
- rounded_rect(cr, 16, 16, 112, 112, radius);
+ rounded_rect(cr, 16, 16,
+ d->frameWidth - 16,
+ d->frameHeight - 16,
+ radius);
cairo_fill(cr);
cairo_destroy(cr);
blur_surface(d->shadow, 64);
d->active_frame =
- cairo_image_surface_create (CAIRO_FORMAT_ARGB32, 128, 128);
+ cairo_image_surface_create (CAIRO_FORMAT_ARGB32,
+ d->frameWidth, d->frameHeight);
cr = cairo_create(d->active_frame);
cairo_set_operator(cr, CAIRO_OPERATOR_OVER);
cairo_set_source_rgba(cr, 0.8, 0.8, 0.4, 1);
- rounded_rect(cr, 16, 16, 112, 112, radius);
+ rounded_rect(cr, 16, 16,
+ d->frameWidth - 16,
+ d->frameHeight - 16,
+ radius);
cairo_fill(cr);
cairo_destroy(cr);
d->inactive_frame =
- cairo_image_surface_create (CAIRO_FORMAT_ARGB32, 128, 128);
+ cairo_image_surface_create (CAIRO_FORMAT_ARGB32,
+ d->frameWidth, d->frameHeight);
cr = cairo_create(d->inactive_frame);
cairo_set_operator(cr, CAIRO_OPERATOR_OVER);
cairo_set_source_rgba(cr, 0.6, 0.6, 0.6, 1);
- rounded_rect(cr, 16, 16, 112, 112, radius);
+ rounded_rect(cr, 16, 16,
+ d->frameWidth - 16,
+ d->frameHeight - 16,
+ radius);
cairo_fill(cr);
cairo_destroy(cr);
}
--
1.7.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Move window frame surface dimensions into struct display and begin using them in place of hardcoded values
2011/2/7 Kristian Høgsberg : > On Sun, Feb 6, 2011 at 11:14 PM, Chris Morgan wrote: >> clients/window.c | 44 +++- >> 1 files changed, 35 insertions(+), 9 deletions(-) > > Hi Chris, > > I was thinking that we could introduce a struct frame type-of-thing > that could hold the different frame details - the cairo surfaces, the > dimensions etc. And please follow the coding conventions in the code. > > Kristian > Would there be one of those things for each of the frame surfaces? After looking more at the code I'm wondering if we shouldn't just render the frame and decorations on demand. Some of the difficulty comes from the tile_source() and tile_mask() code needing to know the window border width found in 'struct window' as well as the frame dimensions. Plus the cairo to draw the frames appears to be quite a bit simpler than the masking code. Is the concern the performance in drawing? Maybe it isn't a big deal with card acceleration? Chris ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] - Add the wayland-build.sh script to building.html and to the directory
On Fri, Feb 4, 2011 at 11:02 PM, Chris Morgan wrote: > Darxus' build scripts made getting, building and running wayland very > easy. It seems useful to provide these to users on the official > wayland site to lower the barrier to getting started with wayland. > > I combined two of them together and split some of the functionality > out into separate commands to make it easier to update, rebuild etc. I > also added a brief mention to the top of the building.html. > > Chris > Any interest in patches like this to provide scripts to help users that might want to get started with wayland? Chris ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] - Map enum window_location to enum wl_shell_resize for the call to wl_shell_resize() to match the type used in shell_resize()
On Sat, Feb 5, 2011 at 10:33 PM, Chris Morgan wrote: > > Patch ok except for the short style c comments? I was going to regenerate it but didn't want to spend the time if there was no interest in the patch. I think the patch makes sense since it provides that hidden mapping between the two enums that otherwise is difficult to spot without knowing it in advance. Chris ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/3] Resubmit - Unit test framework for Wayland
> I found that a good testing framework can lower the barrier of writing > useful tests. Nice logging and status reports are important I feel. And > if for example you can easily write data driven tests, then testing all > possible code paths in a critical area becomes straight-forward and the > tests will remain readable (and with that, maintainable; people tend > forget that every test also adds to the overall maintenance costs which > can often enough outweight the benefits of the test). It's actually the > one thing I really like about Qt's testlib. > +1 for leveraging a framework instead of writing another one :-) ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/3] Resubmit - Unit test framework for Wayland
2012/3/2 Kristian Høgsberg : > On Fri, Mar 2, 2012 at 9:30 AM, Chris Morgan wrote: >>> I found that a good testing framework can lower the barrier of writing >>> useful tests. Nice logging and status reports are important I feel. And >>> if for example you can easily write data driven tests, then testing all >>> possible code paths in a critical area becomes straight-forward and the >>> tests will remain readable (and with that, maintainable; people tend >>> forget that every test also adds to the overall maintenance costs which >>> can often enough outweight the benefits of the test). It's actually the >>> one thing I really like about Qt's testlib. >>> >> >> +1 for leveraging a framework instead of writing another one :-) > > Sorry, this is not helpful. If you have a point to make that's not > already covered in the thread, please do. But if you want to +1 > something, go use Google+, they're big on that. > > Kristian Just saying that I've written a ton of nunit unit tests for projects and I've found that particular framework to be very useful in separating out the tests, reporting results etc. I've gone the write my own way before and it wasn't as productive. Chris ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
zwp_tablet_tool_v2 button definitions
This is all in the context of the zwp_tablet_tool_v2 interface,
based on implementing tablet-v2 for smithay-client-toolkit this week.
Whereas 'type' is enumerated:
event type {
tool_type: uint,
}
enum type {
pen = 0x140,
eraser = 0x141,
brush = 0x142,
…
}
(and the values happen to correspond to linux/input-event-codes.h,
which fact is not mentioned, for better or for worse:
BTN_TOOL_*, except that BTN_TOOL_RUBBER is named eraser)—
Yet 'button' is just a uint, with no explanation whatsoever:
event button {
…
/// The button whose state has changed
button: uint,
…
}
I was perplexed at my pen emitting 331 and 332,
having expected something like 0 and 1, or 1 and 2;
until I discovered the codes matched BTN_STYLUS and BTN_STYLUS2.
I found a thread on this list from the time of initial implementation:
.
The discussion revealed some of why it didn’t end up an enum,
but seemed to kinda tail off inconclusively with a “do what you wish”,
and we’ve ended up with input event codes, but undocumented.
(The thread also reminded me that styli are not the only tablet tools:
I presume mouse tools would use mouse button codes;
and I’m curious what finger tools would do, or if there are others.)
Some questions:
1. Is there any canonical source of information about what codes may be used?
Or are these things just held together by shadowy convention and duct tape?
2. The web’s Pointer Events API treats eraser as a button,
but I get the impression that here they’d be modelled as a separate tool;
is this correct?
(My pen doesn’t have an eraser.)
3. Can we improve the documentation in wayland-protocols,
to at least specify where button codes come from,
and which codes are expected and/or plausible?
(I can contribute, but need clarity on such values first.)
4. *Is* it possible to turn it into an enum?
(Depending on the strength of the customs,
this may not be wise even if possible.
But even in that case, I’m still idly curious.)
— Chris
