Touchscreen support for Touchscreens on amd64 and i386 platforms

[larafercue_gmail.com]

Summary

A couple of kernel configuration files adding support for touchscreens

[• hselasky]

Can you write a few words why this is needed? Isn't wmt loaded by demand?

[larafercue_gmail.com]

In D16721#355542, @hselasky wrote:

Can you write a few words why this is needed? Isn't wmt loaded by demand?

wmt can be loaded by demand, but it must be during loader(8).

Although, the evdev support is needed on the kernel. The kernel files could also be named as EVDEV because it also could allow people to extend them for all kind of evdev devices.

[• hselasky]

I'm just wondering if the name TOUCHSCREEN is too generic.

Have you considered names like GENERIC-EVDEV , like there is GENERIC-NODEBUG ?

--HPS

[trasz]

Why not just add evdev and wmt to GENERIC?

[larafercue_gmail.com]

In D16721#356013, @trasz wrote:

Why not just add evdev and wmt to GENERIC?

Actually, after talking with @zeising that's a good possibility, but only after I figure out why my touchscreen is not working any longer (so far, r333666 worked)

[larafercue_gmail.com]

Putting the evdev support and touchscreen support to GENERIC

[zeising]

I'm not sure that the actual devices need to go into generic, perhaps they can be loaded by devmatch or similar. I haven't looked into this though.

[larafercue_gmail.com]

In D16721#356744, @zeising wrote:

I'm not sure that the actual devices need to go into generic, perhaps they can be loaded by devmatch or similar. I haven't looked into this though.

Well, the evdev device option is needed to compile the EVDEV_SUPPORT option and if wmt is not loaded at boot time, the touchscreen is recognized as HID

[• hselasky]

I think the reason HID picks up the device first will be solved by:
https://reviews.freebsd.org/D16735

So basically we only need device evdev and optinos EVDEV_SUPPORT in GENERIC?

--HPS

[wulf]

In D16721#357529, @hselasky wrote:

So basically we only need device evdev and optinos EVDEV_SUPPORT in GENERIC?

options EVDEV_SUPPORT is irrelevant to wmt. It enables evdev in hybrid (both legacy+evdev inrerfaces) device drivers. wmt is not one of those.
device evdev is not strictly necessary for wmt too if it is not compiled into kernel statically. evdev.ko can be kld-loaded on demand at run-time

Currently wmt is not picked by devmatch because of 2 reasons:

1. PNP record is not committed yet.
2. Even when PNP record is included it loses loading race with uhid.ko

So, to make wmt a winner I inserted kldload directly into devd.conf in my setup:

# Generic MS-touch compatible devices                                                                       
notify 100 {                                                                                                
        match "system"          "USB";
        match "subsystem"       "INTERFACE";
        match "type"            "ATTACH";
        match "intclass"        "0x03";
        match "intsubclass"     "0x00";
        match "intprotocol"     "0x00";
        action "kldload -n wmt";
};

[zeising]

Hi!
Is it possible to split this revision into two parts? I'd like to see the EVDEV support go in, especially the option, since that can't be done runtime. The wmt device can be loaded at runtime and doesn't need to be in the kernel, I believe.

[wulf]

In D16721#377716, @zeising wrote:

Hi!
Is it possible to split this revision into two parts? I'd like to see the EVDEV support go in, especially the option, since that can't be done runtime. The wmt device can be loaded at runtime and doesn't need to be in the kernel, I believe.

wmt(4) loading can be handled at runtime with GENERIC kernel. See: https://reviews.freebsd.org/D17689

[larafercue_gmail.com]

In D16721#377716, @zeising wrote:

Hi!
Is it possible to split this revision into two parts? I'd like to see the EVDEV support go in, especially the option, since that can't be done runtime. The wmt device can be loaded at runtime and doesn't need to be in the kernel, I believe.

I will remove the wmt(4) part as soon as I can.

[zeising]

In D16721#378099, @roberfern_gmail.com wrote:

I will remove the wmt(4) part as soon as I can.

Thank you!
Just let me know if I can help in any way!
Regards
Niclas

[zeising]

In D16721#378099, @roberfern_gmail.com wrote:

In D16721#377716, @zeising wrote:

Hi!
Is it possible to split this revision into two parts? I'd like to see the EVDEV support go in, especially the option, since that can't be done runtime. The wmt device can be loaded at runtime and doesn't need to be in the kernel, I believe.

I will remove the wmt(4) part as soon as I can.

Have you made any progress on updating the diff?
Let me know if I can help in any way.
Regards

[larafercue_gmail.com]

In D16721#381520, @zeising wrote:

In D16721#378099, @roberfern_gmail.com wrote:

In D16721#377716, @zeising wrote:

Hi!
Is it possible to split this revision into two parts? I'd like to see the EVDEV support go in, especially the option, since that can't be done runtime. The wmt device can be loaded at runtime and doesn't need to be in the kernel, I believe.

I will remove the wmt(4) part as soon as I can.

Have you made any progress on updating the diff?
Let me know if I can help in any way.
Regards

Sorry Niclas, I am overwhelmed at work and privately. The worst thing is that I have the means to test it because my laptop has a touchscreen and I can test if something is broken. I'll keep you updated, but it should only be necessary to delete the last 3 lines

[zeising]

The evdev part of this was just committed. I believe this review can be abandoned, as wmt can be loaded on demand.

[larafercue_gmail.com]

In D16721#383764, @zeising wrote:

The evdev part of this was just committed. I believe this review can be abandoned, as wmt can be loaded on demand.

Being that the case, yes. We can abandon this review. Is there a possibility to close it or something similar?