matteodelabre / waved Goto Github PK

Can someone help me with the product-market fit pyramid:

Market:

1. Who is the user of this product? RM user who wants more features? cares about ethical software?
2. What is the un-met need?

Product:

1. What is the value proposition?
2. Key features.
3. UI/X

Thank you! I promise to update the README if you believe it will increase the Monthly Active Users (MAU) of this interesting experiment/product!

There is a buffer overflow in the following call to msgrcv:

As per the man page, the msgsz argument (third argument) should not include the size of the mtype field, only of the data field, so currently this call will overwrite 4 extra bytes to memory, potentially corrupting adjacent structures.

(Related to ddvk/remarkable2-framebuffer#89.)

I see you are developing it as GPL3, and, if I'm understanding it correctly, what you are writing is a library to which you can link your application and draw faster to the rm2 framebuffer (just like xochitl does, by being linked to a static library that does all the framebuffer work from user space).

If that's correct, then I guess this would imply that only GPL apps could use your library, wouldn't it? I'm not planning on releasing commercial apps for the rm2, but I write for several platforms, and I'm afraid that by porting to the rm2 with your lib, I'd might need to change my permissive licenses.

BTW, how far is it from being usable from apps? Would it be possible to use it already as it is? Does it have the usual features needed for low latency? Just trying to find a good alternative to the rm2fb hack...

Hey - could this be generalized to support other devices? I have a Boox Nova Pro which uses the Maxim 17135 pmic (which I thought was also used on the Remarkable 2 but I guess not?).... but if it's purely software based, and not using the imx epdc, wouldn't it also work?

C++ is nice, but one of its major disadvantages is that it's not easy or fun to FFI to it from other languages. Since name mangling, std::string layout, and so on are completely unspecified, other languages have a really really hard time interacting with C++ functions, even when the bindings are auto-generated by a C++ compiler.

waved needs to offer a C API - or else people simply won't be able to use it. The C API can't include any C++ classes/templates such as std::string, since that can't be created or touched by other languages.

All functionality of waved needs to be accessible - the C API should be the main interface (even if it uses C++ internally). If you do this right, not only will people be able to use it directly in applications but a robust display server can be implemented in a language like Rust with little friction.

See mxc_epdc_fb_damage & libqsgepaper-snoop.

The mxcfb driver has a mode where, when an update is processed, any other pending update with the same mode and an overlapping region is merged to be processed at the same time. This could reduce update latency in scenarios where a lot of small updates are coming (for example when drawing in Xochitl).

The exact behavior could be configured by the user. Also see MXCFB_SET_UPDATE_SCHEME (section 6.4.5.11 of the i.MX reference manual).

Some ideas of user-configurable options:

• Screen orientation
• Inverted colors
• Contrast
• Power down delay