Graphics from go on the kobo?

[nihilazo]

Hi,
I'd like to write an application (a browser for the gemini protocol) for the kobo in go, but the only way I have found to draw to the screen from a go program is through fbink (which is great but a little limited for what I'd like).
Is there some other way to draw to the screen/get touchscreen events from a go program?

Thanks!

[NiLuJe]

That'd be a no . The only other remotely viable approach is a full custom Qt5 stack (àla pbchess/UMR).

Fair warning in advance: Whatever you go with, input is going to be a major PITA. There's a reason almost nothing out there handles all the corner-cases properly, except for the stock Qt QPA, which we can't use, and Plato. KOReader is a close second, and that mainly because it forgoes hardware rotation handling (and what little it deals with on that front is relegated to FBInk via fbdepth), which avoids a nice chunk of the potential issues.
(Purely coincidental example: https://github.com/llandsmeer/inkvt/pull/14)

Out of curiosity, what's the hangup with FBInk?

[sherman]

I did a bit of exploratory work with touch input in Go a while ago. You can find it here: go-kobo-input. I also created an experimental on-screen keyboard as well, which can be found at go-osk.

The above probably still has some potential, if anyone wants to dust off the code. The input code probably needs to handle device specific rotation/mirroring handling though, as at the time, I was testing it with my old H2O.

[geek1011]

Originally Posted by nihilazo

but the only way I have found to draw to the screen from a go program is through fbink (which is great but a little limited for what I'd like)

If the issue is that you don't want to call FBInk with os.Exec, sherman has made a CGO wrapper for it. If you want to avoid FBInk entirely, you may have luck porting Plato's FB and input handling to Go directly since it's quite well written and easy to read.

If the issue is that you want more sophisticated text layout and rendering, note that you'll still need to deal with it no matter what you use (unless you're using a GUI toolkit with support for it, or embedding a minimal browser engine to do the rendering for you). Personally, I'd use Pango/Cairo, but Skia is another option.

[nihilazo]

Originally Posted by NiLuJe

That'd be a no . The only other remotely viable approach is a full custom Qt5 stack (àla pbchess/UMR).

Fair warning in advance: Whatever you go with, input is going to be a major PITA. There's a reason almost nothing out there handles all the corner-cases properly, except for the stock Qt QPA, which we can't use, and Plato. KOReader is a close second, and that mainly because it forgoes hardware rotation handling (and what little it deals with on that front is relegated to FBInk via fbdepth), which avoids a nice chunk of the potential issues.
(Purely coincidental example: https://github.com/llandsmeer/inkvt/pull/14)

Out of curiosity, what's the hangup with FBInk?

The hangup with fbink is that I can't see how to do things beyond text and already stored images with it, although I'm probably being dumb.

[sherman]

Originally Posted by nihilazo

The hangup with fbink is that I can't see how to do things beyond text and already stored images with it, although I'm probably being dumb.

You can feed raw scanlines to fbink, so one can programmatically draw to a buffer, and pass that to FBink for display.

go-fbink-v2 for example has a convenience "PrintRBGA" function, which displays an image.RGBA. You could use a library like gg to draw to an image.RGBA, then display it with "PrintRBGA"

One of these days, it would be cool to have a pure Go solution for printing to screen, but that isn't today...

[nihilazo]

Originally Posted by sherman

You can feed raw scanlines to fbink, so one can programmatically draw to a buffer, and pass that to FBink for display.

go-fbink-v2 for example has a convenience "PrintRBGA" function, which displays an image.RGBA. You could use a library like gg to draw to an image.RGBA, then display it with "PrintRBGA"

One of these days, it would be cool to have a pure Go solution for printing to screen, but that isn't today...

Oh awesome, I'll try that out!

[NiLuJe]

Yeah, the idea was to keep things to what I'm interested in first and foremost (i.e., messing with the mxcfb quirks), and what I'm halfway decent at second, which most decidedly is NOT maths and drawing primitives ;p.

So the current stance is: bake your pixmap using tools written by people who actually know what they're doing, and *then* feed it to fbink_print_raw_data ^^.

[nihilazo]

Originally Posted by sherman

I did a bit of exploratory work with touch input in Go a while ago. You can find it here: go-kobo-input. I also created an experimental on-screen keyboard as well, which can be found at go-osk.

The above probably still has some potential, if anyone wants to dust off the code. The input code probably needs to handle device specific rotation/mirroring handling though, as at the time, I was testing it with my old H2O.

Is this input code usable in its current state or does it need more work to get there?

[sherman]

Originally Posted by nihilazo

Is this input code usable in its current state or does it need more work to get there?

I haven't touched (heh) it in a long time, so probably needs work.

More specifically, proper rotation/mirroring support needs to be added.