Drop moused.conf hacks.

Run moused with devd

I have no strong opinion if this right or not. This list is derived from Linux driver with no modifications.
Probably, it has many more duplications. All vendor "0x0bda" devices are handled by generic Realtek entry.

I will try to address comments on weekend

Fix paths in msconvd rc script

In D52164#1191671, @ziaee wrote:

Is this the one Yusuf and I have been testing from your GitHub?

I know about a dozen of persons who tested it.

LGTM

Committed as 4a04e0a6

Committed as adc2c156acb50bac6e8ec66b72cadc8910ce4975

IMO we can go forward and commit this change before code slush..
FIDO/U2F driver is under review. And moused is in a good enough shape to be widely tested. Both of them are minor changes and i think can be committed after August 8.

In D51609#1178825, @emaste wrote:

This is identical to D50550, right? Sorry I didn't make it further in separating these parts as you've done; I'll abandon D50550 and you can land this in this series.

LGTM

Duplicate of D51612

In D51107#1166799, @takawata wrote:

In D51107#1166682, @wulf wrote:

There are more ArrowLake I2C device ids: 7750 and 7751. At least in share/misc/pci_vendors

According to the Datasheet, I2C#4(7750),I2C#5(7751) only supports PIO mode, and I'm not sure the PIO mode only device will work or not.

https://edc.intel.com/content/www/us/en/design/products-and-solutions/processors-and-chipsets/core-ultra-200h-and-200u-series-processors-datasheet-volume-1-of-2/intel-serial-i-o-inter-integrated-circuit-i2c-controllers/

There are more ArrowLake I2C device ids: 7750 and 7751. At least in share/misc/pci_vendors

LGTM

LGTM

As number of object types we handle in LKPI does not exceed 10 it may counts as not a rewrite of ACPICA

In D50863#1161018, @imp wrote:

In D50863#1161017, @wulf wrote:

In D50863#1161016, @imp wrote:

Proper compat symbols will also make future ports easier

It is not about of proper symbols. It is about of adding of LKPI objects which differs only in character case in the name

Which is just as trivial to paper over with #defines so you don't have to change it next time which makes future ports faster since you don't have to detour around already solved trivial problems. When I've done it for other things in the tree, it's helped prevent death of a thousand cuts...

In D50863#1161016, @imp wrote:

Proper compat symbols will also make future ports easier

In D50863#1161012, @bz wrote:

In D50863#1161009, @wulf wrote:

General convention in at least drm-kmod is to not redefine ACPICA objects if it is possible. Porting of this code is mostly just a changing of symbol case and adding/removing of underscores. drm-kmod does not even guards these changes with #ifdefs

I picked a random file ( in v6.6 drivers/gpu/drm/radeon/radeon_acpi.c ) and it seems everything there got CamelCased without any #ifdefs. It's just an unnecessary diff to vendor and maintenance.

No idea how much of this was done in drm-kmod but I am not going to rewrite case in entire files because of this. I had not compiled files or #ifdef'ed out the entire logic. Not gong to fly anymore. Remove the #ifdefs from drm-kmod and reduce the diff to upstream and make maintenance easier by having one place to edit and not 117. That's what LinuxKPI is for.

General convention in at least drm-kmod is to not redefine ACPICA objects if it is possible. Porting of this code is mostly just a changing of symbol case and adding/removing of underscores. drm-kmod does not even guards these changes with #ifdefs

@dumbbell FYI. Take a look at https://github.com/lutzbichler/drm-kmod/tree/pr/6.15. It seems that lutzbichler has advanced to drm-kmod v6.15

In D50315#1158083, @arrowd wrote:

Yep, I messed up and it was still using libinotify's libinotify.h. I've redone the test properly and found that the program starts behaving differently if linked to libinotify.

The test I'm running is

./inotify-test .
touch a
rm a

When not linked with libinotify, I get

a created in watched directory
a was opened
a opened for writing was closed
a delete from watched directory

When linked to libinotify, I only get

a created in watched directory
a deleted from watched directory

I don't think it is worth fixing, because this mess can only arise for 15-CURRENT users that do not recompile their ports after this change hits the tree.

In D50315#1156202, @markj wrote:

In D50315#1155735, @wulf wrote:

As I see, libinotify event values were just copied from Linux, so it may have sense to change system ones to make linuxolator support simpler

This is fine for most of the flags, I will change it. libinotify has this weird thing:

37 /* Flags for the parameter of inotify_init1. */                                                                                                                                                                                                                                                                           
38 #define IN_CLOEXEC      02000000        /* Linux x86 O_CLOEXEC */                                                                                                                                                                                                                                                         
39 #define IN_NONBLOCK     00004000        /* Linux x86 O_NONBLOCK */

Some applications will call inotify_init1(O_CLOEXEC) instead of specifying IN_CLOEXEC. In my inotify.h I just defined those flags to be equal, but to preserve compatibility with libinotify we have to support both values. I guess this is best handled in libc.

As I see, libinotify event values were just copied from Linux, so it may have sense to change system ones to make linuxolator support simpler

Current ABI is not compatible. libinotify events have different values compared with system provided ones.
You must use libinotify header to link with libinotify or change system one to be ABI-compatible.

LGTM

LGTM

In D50498#1153913, @aokblast wrote:

@wulf Are you still have concern on the read_kbd_data? If not, I plan to create the patch for merging.

Should we cache read_kbd_data() rather than reread it?

In D50315#1150660, @markj wrote:

In D50315#1150102, @wulf wrote:

In D50315#1149915, @markj wrote:

In D50315#1149724, @arrowd wrote:

In test "Bugfix tests":

failed: receive IN_ATTRIB for bugst-workdir/1 on hardlink delete
failed: Not receive IN_DELETE_SELF for bugst-workdir/1 on hardlink delete

This one is tricky to fix, I need to think about it.

IIRC IN_DELETE_SELF is generated when the file link number goes from 1 to 0