[hackers] [scroll] fix mismatch of several esc seq. in one input || Jan Klemkow
commit baaf9c0bb7db5e59ffb4f08e2f4383b29dd5a52e
Author: Jan Klemkow
AuthorDate: Fri Apr 24 22:22:08 2020 +0200
Commit: Jan Klemkow
CommitDate: Fri Apr 24 22:26:06 2020 +0200
fix mismatch of several esc seq. in one input
scroll does not detect two esc seq. with scroll up/down
command in the input buffer and handle it as regular input.
By using strncmp(3) with strlen(3) of the matching sequence,
we detect the fist command and irgnore the rest of the input
buffer.
diff --git a/scroll.c b/scroll.c
index ef9d5cd..e147bbd 100644
--- a/scroll.c
+++ b/scroll.c
@@ -493,7 +493,8 @@ main(int argc, char *argv[])
goto noevent;
for (size_t i = 0; i < LENGTH(rules); i++) {
- if (strcmp(rules[i].seq, input) == 0) {
+ if (strncmp(rules[i].seq, input,
+ strlen(rules[i].seq)) == 0) {
if (rules[i].event == SCROLL_UP)
scrollup(rules[i].lines);
if (rules[i].event == SCROLL_DOWN)
Re: [hackers] Announcing libschrift (a TrueType font rendering library)
On 2020-04-24, Silvan Jegen wrote: > Yeah, that's where my missing understanding of graphics programming > becomes apparent. I assumed a font rendering library will just take a > pointer to some memory as an argument to its rendering function to which > it will then write the bitmapped glyph. Surely you will have to take the > different buffer formats into account there though so I am not sure how > that would work. You would also have to consider how the glyph should be blended with the destination, whether you want to use mask image (for example to render in different colors or with transparency), and other details. Rendering the glyphs to separate images in a grayscale format gives the most flexibility. This also allows you to cache the glyphs so you don't have to re-render them all the time. > I'm also stomped by how the shared memory (like wl_shm) differs in Wayland > from a buffer you would get from EGL (like dmabuf-based wl_buffers) or > another graphics library. I thought I could just use pixman to render > into both but I don't think that's actually true... This example[0] > definitely looks relevant to this topic. The buffers you get from OpenGL/Vulkan are generally tiled in various vendor-specific (or even model-specific) formats, meaning they don't use a linear memory layout. If you were to render into it as if it were linear, you'd get jumbled output on the screen. The GPU memory is also not necessarily accessible by the CPU. There are ways to allocate an image in a linear layout backed by host-mappable memory, but that is likely to come with performance penalty (comparatively). Usually, you would only do this to upload textures to the GPU. Recently, most GPU vendors have agreed to settle on an opaque 64-bit "format modifier", which can be passed between APIs along with the DMA-BUF fd so they know how the image is laid out in memory. Previously, the image layout was either assumed, or passed along through some out-of-band channel (for example, AMD stores this information in a metadata structure associated with the buffer). I've been working off-and-on for a while on a library[0] to provide some sort of API to do simple 2D rendering and presentation operations that can be implemented with XRender, Vulkan, pixman, and also directly by submitting command buffers to the GPU. It's meant to be the successor to wld, but I still have a really long way to go, and have not begun to thing about how text rendering would work (but when I do, I'll definitely be looking at libschrift). [0] https://git.sr.ht/~mcf/libblit/
Re: [hackers] [scroll][PATCH]] distclean should remove things created in dist
Thanks! * Steve Ward [2020-04-24 06:43]: --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 7d7b6d8..b577876 100644 --- a/Makefile +++ b/Makefile @@ -25,7 +25,7 @@ clean: rm -f scroll ptty distclean: clean - rm -f config.h + rm -f config.h scroll-$(VERSION).tar.gz dist: clean mkdir -p scroll-$(VERSION) -- 2.20.1 signature.asc Description: PGP signature
Re: [hackers] Announcing libschrift (a TrueType font rendering library)
Hi Michael Thanks for your input! Michael Forney wrote: > On 2020-04-23, Silvan Jegen wrote: > > I had a quick look and currently it looks like it's mostly useful for > > rendering of fonts in X. I wonder how an interface would look like that > > could also be used for text rendering for a Wayland client. I assume the > > library would instead just render to some graphics memory to be rendered > > by the compositor, but I am not completely sure. > > I think the interface would look the same for Wayland, but the missing > piece is something to composite the glyphs into the application's > window buffer, which is handled by XRender in the demo. > > If you are rendering to shared memory, pixman (which is essentially > XRender in a library) can be used similarly. You can create a glyph > cache, load the glyph images produced by libschrift into it, and then > use pixman_composite_glyphs to render them onto your frame. > > For OpenGL/Vulkan, it's the same on X11 and Wayland, since the client > is doing direct rendering in both cases. I believe it's generally done > by creating an "atlas" texture containing a bunch of glyphs at > different positions, and then rendering subregions of it onto your > frame. Most code using freetype directly could probably be adapted to > libschrift fairly easily. Yeah, that's where my missing understanding of graphics programming becomes apparent. I assumed a font rendering library will just take a pointer to some memory as an argument to its rendering function to which it will then write the bitmapped glyph. Surely you will have to take the different buffer formats into account there though so I am not sure how that would work. I'm also stomped by how the shared memory (like wl_shm) differs in Wayland from a buffer you would get from EGL (like dmabuf-based wl_buffers) or another graphics library. I thought I could just use pixman to render into both but I don't think that's actually true... This example[0] definitely looks relevant to this topic. These are the questions I will have to answer for myself before I will be able to contribute much there, I am afraid. Cheers, Silvan [0] https://github.com/wayland-project/weston/blob/master/clients/simple-dmabuf-egl.c
[hackers] [scroll] ] distclean should remove things created in dist || Steve Ward
commit 0e988260cd70fb1b6bbe342d14d927fde29ffbba Author: Steve Ward AuthorDate: Fri Apr 24 06:43:39 2020 -0400 Commit: Jochen Sprickerhof CommitDate: Fri Apr 24 12:55:30 2020 +0200 ] distclean should remove things created in dist diff --git a/Makefile b/Makefile index 7d7b6d8..b577876 100644 --- a/Makefile +++ b/Makefile @@ -25,7 +25,7 @@ clean: rm -f scroll ptty distclean: clean - rm -f config.h + rm -f config.h scroll-$(VERSION).tar.gz dist: clean mkdir -p scroll-$(VERSION)
[hackers] [scroll][PATCH]] distclean should remove things created in dist
--- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 7d7b6d8..b577876 100644 --- a/Makefile +++ b/Makefile @@ -25,7 +25,7 @@ clean: rm -f scroll ptty distclean: clean - rm -f config.h + rm -f config.h scroll-$(VERSION).tar.gz dist: clean mkdir -p scroll-$(VERSION) -- 2.20.1
