Wayland: crash fl_read_image()

[wcout]

I have here an old test program using fl_read_image(), that crashes with Wayland:

image_cursor_wayland.cxx.txt

Program received signal SIGSEGV, Segmentation fault.
0x00000000004a105d in Fl_Wayland_Screen_Driver::read_win_rectangle (this=0x516ec0, X=0, Y=0, w=64, h=64, win=
    0x0, ignore=false, p_ignore=0x0) at drivers/Wayland/Fl_Wayland_Screen_Driver.cxx:1324
1324	    q = buffer->draw_buffer + (j+Ys) * buffer->stride + 4 * Xs;
(gdb) bt
#0  0x00000000004a105d in Fl_Wayland_Screen_Driver::read_win_rectangle(int, int, int, int, Fl_Window*, bool, bool*) (this=0x516ec0, X=0, Y=0, w=64, h=64, win=0x0, ignore=false, p_ignore=0x0)
    at drivers/Wayland/Fl_Wayland_Screen_Driver.cxx:1324
#1  0x00000000004688f5 in fl_read_image(unsigned char*, int, int, int, int, int)
    (p=0x0, X=0, Y=0, w=64, h=64, alpha=255) at fl_read_image.cxx:44
#2  0x0000000000441f2a in make_cursor_image(int, int) (W=64, H=64) at image_cursor_wayland.cxx:41
#3  0x00000000004420c8 in main() () at image_cursor_wayland.cxx:55

[Albrecht-S]

@wcout Thanks for the report, I tried it and I can confirm it's a bug. This program reveals AFAICT two issues:

1. fl_read_image() tries to read from the current window rather than "from the current window or off-screen buffer" as documented
2. The custom cursor is not handled correctly under Wayland.

Regarding (1.): The program "works" (kinda, i.e. it doesn't crash) if I change two things:
(a) comment out surf.set_current() so make_cursor_image() draws to the current window

Fl_RGB_Image *make_cursor_image( int W, int H )
{
	Fl_Image_Surface surf( W, H );
	// surf.set_current();

(b) move the code that creates the cursor after wait_for_expose():

	win.show();
	win.wait_for_expose();
	Fl_RGB_Image *rgb = make_cursor_image( box.w()/2, box.h()/2 );
	box.image( rgb );

@ManoloFLTK These changes are only meant for testing. The original program works fine under Windows (wine) and Linux.

Regarding (2.): Although the custom cursor can be created and works with the correct hotspot it is not reset to the normal cursor when it (i.e. its hotspot) leaves the window boundaries. In my tests the cursor seems to be reset to normal when the hotspot leaves the shadow area around the window (which is about 20 px wide in my test with Weston). This is especially weird if you move the cursor from the window to the title bar and further upwards. It is not reset until it's "far" above (20 px) the title bar instead of when it enters the title bar.

Issue (2.) is not strictly on topic but it's related and I thought I'd mention it here anyway. A "better" cursor than the big red circle might help to see this issue better. FWIW, in my tests I changed the hotspot to the top/center position:

    win.cursor( rgb, rgb->w()/2, 1);

Screenshot with "cursor" (hotspot at top center of red circle) about 20 px above the title bar inside green ellipse.

[ManoloFLTK]

The cursor hotspot issue will be considered separately.

[wcout]

Fixed only partially.

With this modified version of my reproducer program, where the fl_read_image() is called from a Fl_Window::handle() method (hit the space key after start) there is no crash, but the image is obviously not read from the offscreen:

image_cursor_wayland2.cxx.txt

[ManoloFLTK]

Should be good now, hopefully.

Instead of fl_read_window(), I would recommend to use the Fl_Image_Surface::image()
member function which works always, whether the image surface is current or not.
This returns a depth-3 Fl_RGB_Image, so you would have to copy it to another memory
area while processing transparency values.

[wcout]

Yes that fixes it. Thank you.
Note: Your change is just in your own fork by now - I applied in manually to my repo.

[ManoloFLTK]

Sorry. It's in the main repo now too.

[ManoloFLTK]

@Albrecht-S : Issue #2 above

The custom cursor is not handled correctly under Wayland.

should be fixed now in the git repo (618eb8f).

[Albrecht-S]

@ManoloFLTK Yes, thanks, this fixes the issue.

PS: Please don't use '#nnn' to refer to anything but issue or PR numbers because GitHub (mis)interprets this always as issue/PR number and adds unintended "user xxx mentioned this issue" messages to the (falsely) referred issue or PR. Sigh :-(