RE: Problem with mmap keyboard.
Sorry for that double post.
It was already solved by Emmanuel.
Fre;D
De : wayland-devel de la part de
Fred vS
Envoyé : mercredi 4 octobre 2023 20:14
À : wayland-devel@lists.freedesktop.org
Objet : Problem with mmap keyboard.
Hello.
I try to make work the "Keyboard event" step from the Wayland-book but the C
demo crash at loading.
The problem comes from the mapping: with that error:
Line 301: wl_keyboard_keymap: Assertion map_shm != MAP_FAILED' failed.
Here is the function:
static void
wl_keyboard_keymap(void *data, struct wl_keyboard *wl_keyboard,
uint32_t format, int32_t fd, uint32_t size)
{
struct client_state *client_state = data;
assert(format == WL_KEYBOARD_KEYMAP_FORMAT_XKB_V1);
// Line 301: Here problem with mapping
char *map_shm = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0);
assert(map_shm != MAP_FAILED);
struct xkb_keymap *xkb_keymap = xkb_keymap_new_from_string(
client_state->xkb_context, map_shm,
XKB_KEYMAP_FORMAT_TEXT_V1, XKB_KEYMAP_COMPILE_NO_FLAGS);
munmap(map_shm, size);
close(fd);
struct xkb_state *xkb_state = xkb_state_new(xkb_keymap);
xkb_keymap_unref(client_state->xkb_keymap);
xkb_state_unref(client_state->xkb_state);
client_state->xkb_keymap = xkb_keymap;
client_state->xkb_state = xkb_state;
}
Why does the mapping fails, I did check fd and size and they are correctly
assigned?
Thanks.
Problem with mmap keyboard.
Hello.
I try to make work the "Keyboard event" step from the Wayland-book but the C
demo crash at loading.
The problem comes from the mapping: with that error:
Line 301: wl_keyboard_keymap: Assertion map_shm != MAP_FAILED' failed.
Here is the function:
static void
wl_keyboard_keymap(void *data, struct wl_keyboard *wl_keyboard,
uint32_t format, int32_t fd, uint32_t size)
{
struct client_state *client_state = data;
assert(format == WL_KEYBOARD_KEYMAP_FORMAT_XKB_V1);
// Line 301: Here problem with mapping
char *map_shm = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0);
assert(map_shm != MAP_FAILED);
struct xkb_keymap *xkb_keymap = xkb_keymap_new_from_string(
client_state->xkb_context, map_shm,
XKB_KEYMAP_FORMAT_TEXT_V1, XKB_KEYMAP_COMPILE_NO_FLAGS);
munmap(map_shm, size);
close(fd);
struct xkb_state *xkb_state = xkb_state_new(xkb_keymap);
xkb_keymap_unref(client_state->xkb_keymap);
xkb_state_unref(client_state->xkb_state);
client_state->xkb_keymap = xkb_keymap;
client_state->xkb_state = xkb_state;
}
Why does the mapping fails, I did check fd and size and they are correctly
assigned?
Thanks.
RE: Problem with mmap keyboard.
Hello!
>“From version 7 onwards, the fd must be mapped with MAP_PRIVATE by the
recipient, as MAP_SHARED may fail.”
Yep, it does the trick, well seen, now all the infos of the keyboard are
working.
>I don’t know which wl_shell version you are using,
Huh, I did copy the source from:
https://wayland-book.com/seat/example.html
But I dont know where/who to advice to fix the code of wayland-book.
Anyway, many thanks Emmanuel for your precious eyes and advices.
I can continue now the Wayland exploration...
Fre;D
De : Fred vS
Envoyé : mercredi 4 octobre 2023 20:44
À : wayland-devel@lists.freedesktop.org
Objet : RE: Problem with mmap keyboard.
Ho, many thanks Emmanuel.
I will deeply study your mail.
By the way, I am busy to translate all the "steps" demos of the Wayland-book
into Pascal:
https://github.com/fredvs/wayland-pascal
Now, Free Pascal compiler can create nice and working "Pure Wayland
applications".
Note too that the C demos in Wayland-book have some ommisions in code ( I added
the fixes in /src/c).
But for the "Keyboard events" step, I am blocked, the C "Keyboard events" demo
in /src/c does not use the key-map, but it works to give the actions of the
keys and the number of the keys. The same for the translated Pascal code.
But ok, I will try to make the map-keyboard working thanks to with your advices.
Many thanks.
Write you later.
Fre;D
De : Emmanuel Gil Peyrot
Envoyé : mercredi 4 octobre 2023 20:28
À : Fred vS
Cc : wayland-devel@lists.freedesktop.org
Objet : Re: Problem with mmap keyboard.
On Wed, Oct 04, 2023 at 06:19:30PM +, Fred vS wrote:
> Hello.
Hi,
>
>
> I try to make work the "Keyboard event" step from the Wayland-book but the C
> demo crash at loading.
>
> The problem comes from the mapping: with that error:
>
>
> Line 301: wl_keyboard_keymap: Assertion map_shm != MAP_FAILED' failed.
>
>
> Here is the function:
>
> static void
> wl_keyboard_keymap(void *data, struct wl_keyboard *wl_keyboard,
> uint32_t format, int32_t fd, uint32_t size)
> {
> struct client_state *client_state = data;
> assert(format == WL_KEYBOARD_KEYMAP_FORMAT_XKB_V1);
>
> // Line 301: Here problem with mapping
> char *map_shm = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0);
We can read in the documentation of this protocol:
https://wayland.app/protocols/wayland#wl_keyboard:event:keymap
“From version 7 onwards, the fd must be mapped with MAP_PRIVATE by the
recipient, as MAP_SHARED may fail.”
I don’t know which wl_shell version you are using, but check that maybe.
> assert(map_shm != MAP_FAILED);
>
> struct xkb_keymap *xkb_keymap = xkb_keymap_new_from_string(
> client_state->xkb_context, map_shm,
> XKB_KEYMAP_FORMAT_TEXT_V1, XKB_KEYMAP_COMPILE_NO_FLAGS);
> munmap(map_shm, size);
> close(fd);
>
> struct xkb_state *xkb_state = xkb_state_new(xkb_keymap);
> xkb_keymap_unref(client_state->xkb_keymap);
> xkb_state_unref(client_state->xkb_state);
> client_state->xkb_keymap = xkb_keymap;
> client_state->xkb_state = xkb_state;
> }
>
>
>
> Why does the mapping fails, I did check fd and size and they are correctly
> assigned?
>
>
> Thanks.
>
--
Link Mauve
RE: Problem with mmap keyboard.
Ho, many thanks Emmanuel.
I will deeply study your mail.
By the way, I am busy to translate all the "steps" demos of the Wayland-book
into Pascal:
https://github.com/fredvs/wayland-pascal
Now, Free Pascal compiler can create nice and working "Pure Wayland
applications".
Note too that the C demos in Wayland-book have some ommisions in code ( I added
the fixes in /src/c).
But for the "Keyboard events" step, I am blocked, the C "Keyboard events" demo
in /src/c does not use the key-map, but it works to give the actions of the
keys and the number of the keys. The same for the translated Pascal code.
But ok, I will try to make the map-keyboard working thanks to with your advices.
Many thanks.
Write you later.
Fre;D
De : Emmanuel Gil Peyrot
Envoyé : mercredi 4 octobre 2023 20:28
À : Fred vS
Cc : wayland-devel@lists.freedesktop.org
Objet : Re: Problem with mmap keyboard.
On Wed, Oct 04, 2023 at 06:19:30PM +, Fred vS wrote:
> Hello.
Hi,
>
>
> I try to make work the "Keyboard event" step from the Wayland-book but the C
> demo crash at loading.
>
> The problem comes from the mapping: with that error:
>
>
> Line 301: wl_keyboard_keymap: Assertion map_shm != MAP_FAILED' failed.
>
>
> Here is the function:
>
> static void
> wl_keyboard_keymap(void *data, struct wl_keyboard *wl_keyboard,
> uint32_t format, int32_t fd, uint32_t size)
> {
> struct client_state *client_state = data;
> assert(format == WL_KEYBOARD_KEYMAP_FORMAT_XKB_V1);
>
> // Line 301: Here problem with mapping
> char *map_shm = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0);
We can read in the documentation of this protocol:
https://wayland.app/protocols/wayland#wl_keyboard:event:keymap
“From version 7 onwards, the fd must be mapped with MAP_PRIVATE by the
recipient, as MAP_SHARED may fail.”
I don’t know which wl_shell version you are using, but check that maybe.
> assert(map_shm != MAP_FAILED);
>
> struct xkb_keymap *xkb_keymap = xkb_keymap_new_from_string(
> client_state->xkb_context, map_shm,
> XKB_KEYMAP_FORMAT_TEXT_V1, XKB_KEYMAP_COMPILE_NO_FLAGS);
> munmap(map_shm, size);
> close(fd);
>
> struct xkb_state *xkb_state = xkb_state_new(xkb_keymap);
> xkb_keymap_unref(client_state->xkb_keymap);
> xkb_state_unref(client_state->xkb_state);
> client_state->xkb_keymap = xkb_keymap;
> client_state->xkb_state = xkb_state;
> }
>
>
>
> Why does the mapping fails, I did check fd and size and they are correctly
> assigned?
>
>
> Thanks.
>
--
Link Mauve
Re: Problem with mmap keyboard.
On Wed, Oct 04, 2023 at 06:19:30PM +, Fred vS wrote:
> Hello.
Hi,
>
>
> I try to make work the "Keyboard event" step from the Wayland-book but the C
> demo crash at loading.
>
> The problem comes from the mapping: with that error:
>
>
> Line 301: wl_keyboard_keymap: Assertion map_shm != MAP_FAILED' failed.
>
>
> Here is the function:
>
> static void
> wl_keyboard_keymap(void *data, struct wl_keyboard *wl_keyboard,
> uint32_t format, int32_t fd, uint32_t size)
> {
> struct client_state *client_state = data;
> assert(format == WL_KEYBOARD_KEYMAP_FORMAT_XKB_V1);
>
> // Line 301: Here problem with mapping
> char *map_shm = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0);
We can read in the documentation of this protocol:
https://wayland.app/protocols/wayland#wl_keyboard:event:keymap
“From version 7 onwards, the fd must be mapped with MAP_PRIVATE by the
recipient, as MAP_SHARED may fail.”
I don’t know which wl_shell version you are using, but check that maybe.
> assert(map_shm != MAP_FAILED);
>
> struct xkb_keymap *xkb_keymap = xkb_keymap_new_from_string(
> client_state->xkb_context, map_shm,
> XKB_KEYMAP_FORMAT_TEXT_V1, XKB_KEYMAP_COMPILE_NO_FLAGS);
> munmap(map_shm, size);
> close(fd);
>
> struct xkb_state *xkb_state = xkb_state_new(xkb_keymap);
> xkb_keymap_unref(client_state->xkb_keymap);
> xkb_state_unref(client_state->xkb_state);
> client_state->xkb_keymap = xkb_keymap;
> client_state->xkb_state = xkb_state;
> }
>
>
>
> Why does the mapping fails, I did check fd and size and they are correctly
> assigned?
>
>
> Thanks.
>
--
Link Mauve
Problem with mmap keyboard.
Hello.
I try to make work the "Keyboard event" step from the Wayland-book but the C
demo crash at loading.
The problem comes from the mapping: with that error:
Line 301: wl_keyboard_keymap: Assertion map_shm != MAP_FAILED' failed.
Here is the function:
static void
wl_keyboard_keymap(void *data, struct wl_keyboard *wl_keyboard,
uint32_t format, int32_t fd, uint32_t size)
{
struct client_state *client_state = data;
assert(format == WL_KEYBOARD_KEYMAP_FORMAT_XKB_V1);
// Line 301: Here problem with mapping
char *map_shm = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0);
assert(map_shm != MAP_FAILED);
struct xkb_keymap *xkb_keymap = xkb_keymap_new_from_string(
client_state->xkb_context, map_shm,
XKB_KEYMAP_FORMAT_TEXT_V1, XKB_KEYMAP_COMPILE_NO_FLAGS);
munmap(map_shm, size);
close(fd);
struct xkb_state *xkb_state = xkb_state_new(xkb_keymap);
xkb_keymap_unref(client_state->xkb_keymap);
xkb_state_unref(client_state->xkb_state);
client_state->xkb_keymap = xkb_keymap;
client_state->xkb_state = xkb_state;
}
Why does the mapping fails, I did check fd and size and they are correctly
assigned?
Thanks.
Re: need help writing tests for specific event orderings
On Wed, 4 Oct 2023 11:26:02 +0300 Pekka Paalanen wrote: > ... > For the forked clients, there is stop_display()/display_resume(). > Maybe that helps? Maybe if I understand their usage correctly. Is this right?: A client would send a sequence of requests followed by a stop_display request. Anything the client sends after that stop_display request will not be processed in the server until the server issues a display_resume event. > ... > If you limit your direct marshalling to sequences that are > theoretically allowed, doesn't that already help you prove that all > those cases are handled correctly? Yes, as long as everyone believes in the "theoretically allowed" part. > ... > But I guess your goal is to see if using the API correctly could ever > trigger an illegal sequence? That's the goal. > ... > It's also possible to call both server and client APIs from the same > thread/process on the same Wayland connection, but you need to be > careful to prove it cannot deadlock. That should be much easier since > it's all single-threaded, and you just need to make sure the fds have > data to read and queues have messages to dispatch when you expect > them. I've been thinking about that. Deadlock is the issue, though. If my understanding of stop_display/display_resume is correct, I might use that. Thanks.
Re: need help writing tests for specific event orderings
On Tue, 3 Oct 2023 14:46:14 -0400 jleivent wrote: > I am trying to write some tests that provoke errors in libwayland, but > it doesn't seem to me like the existing test suite provides a mechanism > to create specific event orderings that are allowed but not guaranteed > by the asynchrony of the protocol. Is that correct? It looks to me > like the tests in the test suite that involve a client and server all > fork the client and allow it and server to run asynchronously without > a way to impose any ordering restriction, but it's hard to tell. If > there is a mechanism to use to get specific event orderings, where is > it? For the forked clients, there is stop_display()/display_resume(). Maybe that helps? > I could simulate one side (the side that doesn't encounter the error) > by directly marshalling the messages it would send into the wire to the > other side. That might be a suitable unit test for after the error is > proven to exist in the field, but it doesn't (conclusively) prove that > the error can exist in the field because of its reliance on simulation > tactics. That's my fallback - but is there a better way? If you limit your direct marshalling to sequences that are theoretically allowed, doesn't that already help you prove that all those cases are handled correctly? It's also useful to test sequences that are theoretically illegal, to ensure they raise the appropriate errors. But I guess your goal is to see if using the API correctly could ever trigger an illegal sequence? I wonder if that's even possible without adding more test hooks inside libwayland. Adding test hooks is possible though, os-wrappers-test.c makes use of some already. It's also possible to call both server and client APIs from the same thread/process on the same Wayland connection, but you need to be careful to prove it cannot deadlock. That should be much easier since it's all single-threaded, and you just need to make sure the fds have data to read and queues have messages to dispatch when you expect them. While it would be bad to do nested dispatch, like client side event handler calling wl_display_dispatch, I believe there should be no problem calling server API from client side handlers and vice versa when everything is single-threaded. Thanks, pq pgpPZYgn_bCxK.pgp Description: OpenPGP digital signature
