Boox (M92) developer community?

[pkbo]

Originally Posted by seaniko7

I don't think I'll get touchscreen working, as its interpreter is based on software layer (touch_server, touch_client using unix socket).

I'm sorry for dumb question (I know little or nothing about linux internals). Could you please ellaborate why this software layer needed? I can see that touch screen events go from /dev/ttymxc1, I also can see that system_manager binds to /tmp/onyx/touch file (don't know what for) and I never saw touch_server among processes.

[zeng]

The reason is performance. The touch server is introduced for scribble and it will not lose any touch points. The default ttymxc1 just for normal GUI mouse events. So basically when using gui events, you should read data from ttymxc1. If you need to do something about scribble, you need to add listener to touch server.

[pkbo]

Thank you very much for the reply. If you happen to be here could you please answer one more question. What is rationale of having udp server driving screen updates? Wouldn't it be better to implement QT Screen plugin and call ioctls there? This way we will not need to modify existing QT software by inserting ScreenProxy here and there just to show something on the screen. And many bugs related to scrren update will be gone.

[zeng]

Actually, it works as what you expected. The screen update including region, waveform and so on is handled in qt screen plugin. In order to optimize screen update from application level, we add ScreenProxy class so that application developer can specify how to update screen instead of auto update by predefined algorithm. Of course, we also add screenUpdateWatcher which is used to automatically update screen. But developers have to modify source code to add the watcher, otherwise there is no screen update.

We don't want to change Qt source code so have to add a plugin to do so. And we cannot find the best approach to automatically update screen in Qt source code directly. So we add manual screen update and auto screen update out of Qt source code. They are screenProxy and ScreenUpdateWatcher.

[pkbo]

I have Kobo launcher by sergeyvl12 running on my M92. It uses QT screen plugin. The plugin is very simple and it doesn't allow to control screen update too much. But it works ok by default. If I want to optimize screen refresh I could extend it to select waveform I need, etc like it is done for example in CR3 for Amazon:

    QKindleFb *pscreen = static_cast<QKindleFb*>(QScreen::instance());
    if (pscreen) pscreen->forceFullUpdate(fullScreen);

The main point is that is works out of the box and I don't even need to recompile Kobo applications, they run as is. The only problem is that I run it as qws server and I have to kill system_manager. This means I will need to implement all system manager functionality (such as power management, usb handling, etc) from scratch and I have nor time nor wish in doing so. That's why I hoped onyx could make something similar.

[pkbo]

That's was bad example , but let me try to explain what I mean. At present your plugin do not refresh the screen while client wouldn't say him to do so. I wont just opposite - your plugin refresh screen by default (AFAIU it has all information needed) while client application wouldn't say don't do it.

With this approach applications will run reasonably well without modifications but if you need some more control on screen refresh you can achieve this by the same ScreenProxy but at this time it will not drive updates but just control how to update (which mode to use) or not update at all when we need to avoid extra flushing. Am I miss something and this approach wouldn't work?

[underscore]

question:
is the touchscreen hw and resolution 'good' ?
i mean, i tried the alternative scribble also, or the empty pdf trick.
But there is no way i can really use it to take lines of handwritten notes like with pen and paper.
Not that i was expecting when i bought it but :-)

[zeng]

The reason why we don't enable screen update automatically is that at the very beginning, it cause too much screen update. So we disable screen update by default.The idea is to remove all unnecessary screen update if possible.

[zeng]

Actually, touch screen is 'good' enough. It responses to your input quickly enough. The problem is eink refresh rate. It's too slow. When you cannot get good feedback from device, you may not draw correctly .

[onyxuser]

https://github.com/onyx-intl/toolcha...ugins/hanvon.c


// for freescale imx508 9.7 inch
samp->y = samp->y * 1200 / 0x2000;
samp->x = samp->x * 825 / 0x1800;

from which we can conclude that digitizer panel has 8192x6144 resolution, but software reduces it to screen resolution

[pkbo]

Originally Posted by zeng

So we disable screen update by default.The idea is to remove all unnecessary screen update if possible.

You don't look for easy ways . Well ok, I can live with what I have right now.

[seaniko7]

Hi there, quick update:
I have Ubuntu working both from sd card and chroot with support for :
- Mouse
- Keyboard
- Wireless

Now, I'll try to get touchscreen working ...

edit:

This post was posted using M92 running Firefox

edit2: some proof

Spoiler:

Also I've prepared alternative monochrome screen controller for even faster screen refresh ( useful in terminal emulator and text editors ) :

Spoiler:

[crazydog]

yeah
you are the best seaniko7

I want to have that too ... please

[Kirith]

Originally Posted by crazydog

yeah
you are the best seaniko7

+1. I am very glad to see such a successful job of porting Linux!!!
There is one wish: to configure the work of 3G-modem. Of the most primitive. This significantly affect the functionality of M92. (Well, to him yet-to Network Manager, but it's much too, probably ...)

+1. Я очень рад видеть столь успешную работу по портированию Linux!!!
Есть одно пожелание: настроить работу 3G-модема. Самого примитивного. Это существенно повлияет на функционал М92. (Ну и к нему ещё-бы Network Manager, но это уже черезчур, наверное...)

[Kirith]

So what's new? impatient to try