I am going to read absolute position from touchpad ,and the simulate a wacom so that oridinary applications like GIMP can be adapted.
I have successfully get absolute position from my touchpad,but where can I get the document on developing a fake wacom driver.
Not sure what you are doing, but start with the actual Wacom Linux driver, and change what you need from that: https://github.com/linuxwacom/input-wacom
Related
How to get screenshot of graphical application programmatically? Application draw its window using EGL API via DRM/KMS.
I use Ubuntu Server 16.04.3 and graphical application written using Qt 5.9.2 with EGLFS QPA backend. It started from first virtual terminal (if matters), then it switch display to output in full HD graphical mode.
When I use utilities (e.g. fb2png) which operates on /dev/fb?, then only textmode contents of first virtual terminal (Ctrl+Alt+F1) are saved as screenshot.
It is hardly, that there are EGL API to get contents of any buffer from context of another process (it would be insecure), but maybe there are some mechanism (and library) to get access to final output of GPU?
One way would be to get a screenshot from within your application, reading the contents of the back buffer with glReadPixels(). Or use QQuickWindow::grabWindow(), which internally uses glReadPixels() in the correct way. This seems to be not an option for you, as you need to take a screenshot when the Qt app is frozen.
The other way would be to use the DRM API to map the framebuffer and then memcpy the mapped pixels. This is implemented in Chromium OS with Python and can be translated to C easily, see https://chromium-review.googlesource.com/c/chromiumos/platform/factory/+/367611. The DRM API can also be used by another process than the Qt UI process that does the rendering.
This is a very interesting question, and I have fought this problem from several angles.
The problem is quite complex and dependant on platform, you seem to be running on EGL, which means embedded, and there you have few options unless your platform offers them.
The options you have are:
glTexSubImage2D
glTexSubImage2D can copy several kinds of buffers from OpenGL textures to CPU memory. Unfortunatly it is not supported in GLES 2/3, but your embedded provider might support it via an extension. This is nice because you can either render to FBO or get the pixels from the specific texture you need. It also needs minimal code intervertion.
glReadPixels
glReadPixels is the most common way to download all or part of the GPU pixels which are already rendered. Albeit slow, it works on GLES and Desktop. On Desktop with a decent GPU is bearable up to interactive framerates, but beware on embedded it might be really slow as it stops your render thread to get the data (horrible framedrops ensured). You can save code as it can be made to work with minimal code modifications.
Pixel Buffer Objects (PBO's)
Once you start doing real research PBO's appear here and there because they can be made to work asynchronously. They are also generally not supported in embedded but can work really well on desktop even on mediocre GPU's. Also a bit tricky to setup and require specific render modifications.
Framebuffer
On embedded, sometimes you already render to the framebuffer, so go there and fetch the pixels. Also works on desktop. You can enven mmap() the buffer to a file and get partial contents easily. But beware in many embedded systems EGL does not work on the framebuffer but on a different 'overlay' so you might be snapshotting the background of it. Also to note some multimedia applications are run with UI's on the EGL and media players on the framebuffer. So if you only need to capture the video players this might work for you. In other cases there is EGL targeting a texture which is copied to the framebuffer, and it will also work just fine.
As far as I know render to texture and stream to a framebuffer is the way they made the sweet Qt UI you see on the Ableton Push 2
More exotic Dispmanx/OpenWF
On some embedded systems (notably the Raspberry Pi and most Broadcom Videocore's) you have DispmanX. Whichs is really interesting:
This is fun:
The lowest level of accessing the GPU seems to be by an API called Dispmanx[...]
It continues...
Just to give you total lack of encouragement from using Dispmanx there are hardly any examples and no serious documentation.
Basically DispmanX is very near to baremetal. So it is even deeper down than the framebuffer or EGL. Really interesting stuff because you can use vc_dispmanx_snapshot() and really get a snapshot of everything really fast. And by fast I mean I got 30FPS RGBA32 screen capture with no noticeable stutter on screen and about 4~6% of extra CPU overhead on a Rasberry Pi. Night and day because glReadPixels got was producing very noticeable framedrops even for 1x1 pixel capture.
That's pretty much what I've found.
I am using a custom davinci board running Arago project. I am using analog video out (PAL), and though the OLED display powers on with uboot, no image comes till the kernel has finished loading. I want to display a logo as soon as uboot starts and display powers on. I tried adding
#define CONFIG_SPLASH_SCREEN
in the uboot config file, but that doesn't work.
One approach I can think of is to put an image in the NAND memory, and then use the
setenv splashimage <address>
command to display it during uboot. But the problem is, I do not know how to put the image in the NAND memory in a particular address.
Alternative methods are also welcome.
Thanks!
The CONFIG_SPLASH_SCREEN only tells U-Boot to include the code required for supporting splash screens. It says absolutely nothing about how to display the splash screen or where to find it. It only provides you with helpful functionality to achieve that goal.
There is no need to put your image at a specific address in NAND. If your U-Boot can access the filesystem, you could just have the image in a file. You could also embed the image in the U-Boot image if you like. That's entirely up to you. The functionality included by the CONFIG_SPLASH_SCREEN will help you load an image from any number of sources.
The trick is getting it displayed. You'll need to teach U-Boot enough about your graphics hardware to get the image out. On most SoCs, that's just a matter of setting up the framebuffer, loading your image into it, and telling the hardware to start clocking it out.
It doesn't look like someone has written a framebuffer driver for the DM365, so you'll have to do that yourself. Or maybe ask on the mailing list if anyone has done it but not contributed it back yet. If you have to do the work yourself, it's probably easiest to start from the Linux driver and port only the bits you need.
You'll find here the official documentation for u-boot's splash. It has an example on how to load the file into nand, using tftp.
Find here how to set the tftp server in case you don't already have.
This is a fairly broad question, so I will try to keep it as focused as I can.
I currently own a Lenovo laptop with Ubuntu installed and touchscreen functionality and own a pressure-sensitive Bluetooth pen, and been trying to make the two work together as a cheap Cintiq-like tablet.
The pen has, unfortunately, support for only specific apps for iOS phones and tablets.
So after lots of research, I've managed to interface with the pen and create a uinput device for it, so I can register button clicks and pressure changes on the pen and even see them routed to GIMP when configuring the device through the Input Controllers menu.
The code I have so far for that interface is available here.
The trouble starts when trying to test it out with GIMP.
From what I gather, this is because GIMP assumes Wacom devices report their own position, treats touchscreen touches as mouse movements and only allows input from a single device at a time.
My question is, how can I work around this?
More specifically, how can I create a uinput device that would behave as a Wacom tablet and supersede/block the behavior I described?
Or if there's a different solution, such as patching GIMP or writing a plugin for it.
Update (2014-06-07)
The code mentioned above now works.
I have written a blog post on the process of getting this to work: http://gerev.github.io/laptop-cintiq
As you said, Gimp expects you to provide ABS_X and ABS_Y along with ABS_PRESSURE in your driver - which is not strange, because you are using you virtual device as input, so it wouldn't make much sense to pick ABS_X and ABS_Y coordinates from one device and ABS_PRESSURE from another (although they will always be the same in this case). Maybe you can just read the current coordinates of the mouse and copy them as your own device coordinates.
As an example, the project GfxTablet does something similar to what you are trying, they have an Android application for tablets with pen and use uinput to create virtual device that works like pressure-sensitive pen on Linux. I have used it and it worked like a charm in Gimp and mypaint on my laptop, and I had no problem with having a mouse (or the touchpad) active at the same time as the uinput device (I think that Krita added support for generic pressure-sensitive devices recently). You can take a look at the source code of the driver here (surprinsingly simple, to be fair).
Note that this is not a faulty behavior of Gimp, because this is what is expected from a tablet-like device. Take a look at the event codes kernel documentation page, in the last section (Guidelines), it is said that tablets must report ABS_X and ABS_Y. Moreover, they should use BTN_STYLUS and BTN_STYLUS2 to report the tool buttons and some BTN_TOOL_* (e.g. BTN_TOOL_PEN) to report activity (you can find all the available codes in input.h); however, these last does not seem that important, as GfxTablet does not implement them and worked without problem.
We have a kiosk application that runs matchbox on top of linux, and has only a barcode scanner for input (no keyboard). It would be great to be able to print a barcode that--when scanned--sent commands like SysRq R etc, so that one could REISUB without having to disassemble the unit.
If there is not an existing way, could you patch the barcode driver to interpret a certain set of symbols and initiate the sequence?
Why do you need SysRq? Is the machine actually wedging itself or are you just trying to reboot cleanly? Why not just put a "reboot" command into whatever protocol you're using? What's wrong with simply doing a hard power cycle?
I want to set up my embedded application as a HID device, with a separate process controlling the HID interface to allow dynamic connections to a PC. There seems to be many people out there that have done it, but I would like to do is:
a) Understand how to configure my build (Freescale i.MX Linux using ltib) to include the USB APIs and includes in my build (ie g_hid.h).
b) Where can I find an example application which does something like move the mouse about the screen to demonstrate the operation of the HID?
Thanx for your help!
http://lxr.linux.no/#linux+v3.3/Documentation/usb/gadget_hid.txt is an example of how to operate a mouse HID.