mouse device representation in linux / may be controlling the mouse by GPIOs

Yea.... it´s me again,

since the last visit i could do some steps forward.
I actually found a way to control single GPIOs from Qt C++ App WITHOUT the need to install anything else or typing "stuff" to the command line.


Questions
1) How is the mouse represented in a linux system?
For example, when one uses a touchdisplay the "mouse commands" are fed into the system somehow different

2.) Could there be a way to control the mouse (cursor and left-click" by GPIO, I2C...?
Even if i need a driver for that.
3.) If there are allready UART, I2C drivers in an image showing up in the /sys/dev or /sys/tty directorys - is it possible to map them into mous controls (pessimisticaly i guess No...)
4.) Are there guides or books dealing around how to write drivers for linux? I´m sure there is no
"How-to-write-I2C-mouse-Driver-for-an-Android-running-Banana-Pi",
but may be a general source with the scope on giving an orientaion of what information has to be gathered. Actually i´m afraid it ends up in bare-metal-programming which makes me dependent to the available documentation of a specific SoC...

best regards!

Originally Posted by Jasson Yea.... it´s me again, since the last visit i could do some steps forward. I actually found a way to control single GPIOs from Qt C++ App WITHOUT the need to install anything else or typing "stuff" to the command line.

Welcome back to LQ

Originally Posted by Jasson Questions 1) How is the mouse represented in a linux system? For example, when one uses a touchdisplay the "mouse commands" are fed into the system somehow different 2.) Could there be a way to control the mouse (cursor and left-click" by GPIO, I2C...? Even if i need a driver for that. 3.) If there are allready UART, I2C drivers in an image showing up in the /sys/dev or /sys/tty directorys - is it possible to map them into mous controls (pessimisticaly i guess No...) 4.) Are there guides or books dealing around how to write drivers for linux? I´m sure there is no "How-to-write-I2C-mouse-Driver-for-an-Android-running-Banana-Pi", but may be a general source with the scope on giving an orientaion of what information has to be gathered. Actually i´m afraid it ends up in bare-metal-programming which makes me dependent to the available documentation of a specific SoC... best regards!

The mouse is an input device. You should see it under /dev/input/mouse0 or something close to that. The information is usually binary. A thing to do is use the sudo command to echo out the mouse0 file and then move your mouse and you'll see some non-printable character representations stream to your terminal. That will confirm you are looking at the resource which is mapped to your mouse.

/dev/input$ sudo cat mouse0 

   





�
�������8����(�8��8��8��8��8��8��8��8��8��8��8��8��8��8��8��8��8��8��8��8��8��8��8�


^C

I've done a lot of Qt programming and the only times I've had to write custom drivers for anything such as using a mouse or keyboard over GPIO, UART, or I2C is if said mouse or keyboard is coming in via that means from some custom embedded board. What the custom driver does is takes the signals and decodes them to where it has discriminated each atomic gesture or intention. Like a numeric keypad may only have 0 through 9 and then enter, so the driver would need to understand eleven different input signal types.

Once you discern the key type from whatever form of input you have, you then can create a QKeyEvent and post it to the Qt engine.

QKeyEvent *thumb_left = new QKeyEvent(QEvent::KeyPress, Qt::Key_Backtab, Qt::NoModifier, "", FALSE, 1);
QApplication::postEvent(scene, thumb_left);

Otherwise if you have a true input device and it is entering input signals via an existing driver, then all you need do is determine which /dev resource is mapped to your input device. Likely if it is one of the normal HID type of drivers, Qt already supports it as an input device.

I've never been very good at finding a single resource to serve my learning needs. I'd look for an online guide about Linux device driver writing, determine if that was either too insufficient or too detailed for me, but read as much as I could stand. And I'd also look for example driver code that I could get through and was also similar to the driver I wished to write. That usually gives me a good indication as to whether or not I was in over my head. Best of luck if you choose to go that route.

Hello rtmistler,

thanks for your detailed answer!!

So do i get it right by this

the only times I've had to write custom drivers for anything such as using a mouse or keyboard over GPIO, UART, or I2C is if said mouse or keyboard is coming in via that means from some custom embedded board.

that my second question can be answered with yes?

2.) Could there be a way to control the mouse (cursor and left-click" by GPIO, I2C...? Even if i need a driver for that.

the only times I've had to write custom drivers for anything such as using a mouse or keyboard over GPIO, UART, or I2C is if said mouse or keyboard is coming in via that means from some custom embedded board.

So, you allready did, what i´m thinking to do? Use a "Pin-hardware" for mouse/keyboard control? To estimate the effort i have to do - i´m i correct i have to do bare-metal-programming?
My way of thinking about a driver is, that is is the layer between hardware and OS. On hardware side the driver talks to the registers of the CPU and presents the results in specific value-types trough an standadized API to the OS.

My "English-To-German-Interface" (LOL) possibly isn´t good enogh to understand this

What the custom driver does is takes the signals and decodes them to where it has discriminated each atomic gesture or intention.

Do you mean by atomic, that every single keyhit or mousemove is recognized? (i know "atomic" in a manner of single-CPU-Tick-Instructions" like mutex-access).
And what means "where" in this context? Can you link me to educational sources you have used for

the only times I've had to write custom drivers

best regards,
Jasson

What I meant by the term atomic was to describe singular inputs at their most fundamental level. Not clock ticks in a CPU, but it is a great analogy because CPU clock ticks are the most fundamental level of CPU activity. On a mouse, the smallest amount of input action. "slide left 1 pixel", "slide down 1 pixel", "left button pressed", "left button released". I think you understand that and were just asking for clarification of my use of terms. Hopefully that makes my intents clear.

I agree that #2 is a yes and that you are thinking about a driver correctly.

At this point you need to therefore write your driver. I'd recommend looking for an existing mouse driver, seeing how it is coded, and try to mimic what it does, in fact, start with it and try to rewrite it so that the lower layer, the part interfacing with the actual hardware is the portion which you change. Thus you may find that you make a real mouse driver for you custom hardware. Which would be your intent.