Support for the mouse ioctl interface

[HongChao6]

Note: Please adhere to Contributing Guidelines.

Summary

Support for the mouse ioctl interface

Impact

mouse driver

Testing

qemu

[nuttxpr]

[Experimental Bot, please feedback here]

No, this PR description does not meet the NuttX requirements. It's far too brief and lacks critical information. Here's why and what's missing:

Summary:

• Insufficient detail: "Support for the mouse ioctl interface" is vague. What specific ioctl calls are added? What functionality do they provide? What problem does this solve (e.g., was there no way to control the mouse before)?
• Missing context: Which part of the codebase is affected? Is this a new driver? Modification to an existing one? A new system call?
• No explanation of how it works: How is the ioctl interface implemented? What are the internal changes?
• Missing issue references: Are there any related issues this PR addresses?

Impact:

• Incomplete answers: Saying "mouse driver" doesn't explain the impact. All the "NO / YES" questions need proper answers with explanations if "YES." For example:
  • Impact on user: Will users need to change their applications to use the new ioctl calls?
  • Impact on hardware: Does this only affect certain mouse hardware or architectures?
  • Impact on documentation: Does this require documentation updates? Has documentation been added?

Testing:

• Inadequate testing description: "qemu" is not enough. What specific qemu configuration was used? What tests were run? What were the expected results?
• Missing logs: The "Testing logs before change" and "Testing logs after change" sections are empty. These are crucial for demonstrating that the change works and doesn't introduce regressions. Include relevant log output showing the mouse functionality before and after the change.
• Missing build host details: What operating system, compiler, and versions were used for the build?

Example of a better Summary:

This PR adds support for the MOUSE_SET_SAMPLERATE and MOUSE_GET_STATUS ioctl calls to the existing mouse driver in drivers/input/mouse.c. These ioctls allow user applications to control the mouse sampling rate and retrieve the current mouse status (buttons, position). This addresses the lack of a standardized interface for interacting with the mouse device, as described in [NuttX Issue #123].

Example of a better Impact Section:

• Is new feature added? YES - Adds ioctl interface for mouse control.
• Impact on user? YES - Users can now use the new ioctls to control the mouse sampling rate and get status. Applications will need to be updated to use these features.
• Impact on build? NO
• Impact on hardware? NO - Works with existing supported mouse hardware.
• Impact on documentation? YES - Documentation has been added to the doc/drivers/input.txt file describing the new ioctl calls and their usage.
• Impact on security? NO
• Impact on compatibility? NO

Example of a better Testing Section:

• Build Host: Linux (Ubuntu 20.04), x86_64, GCC 9.4.0
• Target: qemu-system-arm, sim:nsh config

Testing logs before change:

$ nsh
nsh> mouse_test  # No output, as ioctls are not implemented

Testing logs after change:

$ nsh
nsh> mouse_test
Mouse sampling rate set to 100Hz
Mouse status: Left button pressed, X=100, Y=200

By providing more specific details and filling in the missing information, the PR will be much easier to review and understand, increasing the chances of it being accepted.

[acassis]

@HongChao6 CONFIG_INPUT_MOUSE/TOUCHSCREEN/KEYBOARD are hidden flags only enabled by some other device that implements this feature. Add 'bool "Some text" ' you bring enable the feature to be select-able by the users, even without some driver exist to implement it. I suggest keeping it without text.

[acassis]

@xiaoxiang781216 what do you think?

[terry0012]

In the rpmsg device scenario, the actual input device is located on the remote core, and there is no real hardware driver on local side. In this case, we need to be able to enable the input device option separately so that the application layer can seamlessly use the remote input device.
CC @HongChao6 @xiaoxiang781216 @acassis

[acassis]

@terry0012 and @HongChao6 I understand that, but after you let user to see and enable these symbols it is expected to work. So if user enable Mouse or Keyboard they will expect it so work, but it will not, because it depends on some external driver. So, I think it should to become a new session, like Sensors Driver, after you enable it you should be presented with all Sensors drivers. It means all "select" now should become "depends on"

[acassis]

@raiden00pl @PetteriAimonen @lupyuen please take a look.

I think since now the user will be able to see and enable the Mouse, Touchscreen and Keyboard we need to have the devices organized as a new menu where the user select which Mouse, Touchscreen and/or Keyboard he/she want to use