[Feature Request] The ability to use hidraw instead of i2c #224
Assignees
Labels
enhancement
New feature or request
Comments
|
@Stivux What I do wrong I see no change for device with id |
|
@Stivux For laptop |
|
@ldrahnik what kernel version are you using? I tested it on Fedora with 6.11.4. On new kernel asus-hid is cool improved. Looks like it doesnt work on older kernel. I found other util to dump hid values: https://pypi.org/project/hid-tools How it looks to me: Before numberpad led enabling: After numberpad led enabling: After setting 0x41 brightness (via i2ctransfer for example): After setting 0x48 brightness: |
|
@Stivux I use EOS 7.1: and EOS 8: |
|
@Stivux What a and I will try your version via |
|
@ldrahnik Since I'm on Fedora 41, Python 3.13 |
|
I tested it on Elementary OS 8.0. It works too. Maybe in your case led properties are in other registers? hid-feature list /your/hidraw/path --fetch-values > hid_oldDon't touch touchpad! Probably hid contains also x, y tap position. Change brightness/led status via i2ctransfer for example. hid-feature list /your/hidraw/path --fetch-values > hid_newand diff hid_old hid_new |
|
@Stivux How you installed |
|
@ldrahnik hid-feature is part of hid-tools pip install hid-toolsThen activate virtualenv as root. One more observation: if I disable the i2c-dev module I can't see changing of led feature values. They will be constant. But I can enable and disable led setting all d000* features one time. hid-feature set /dev/hidraw0 -f d0000 112 -f d0000 3 -f d0000 1 -f d0000 83 # led on, brightness 0x43. In this case I can change values (enable/disable led, set brightness), but can't see new value of d0003 for example. Looks like i2c-dev is used to communicate with hidraw devices. It is still useful. You can opt out of using smbus2 package |
|
@Stivux Looks like the same values are displayed to me |
|
|
@Stivux What is your output? |
|
@Stivux What do you see in journal |
|
@ldrahnik Also I tested it on EOS 8.0 Live ISO Do you have the i2c-dev module enabled? |
|
@Stivux Yes, I use it for example for NumberPad |
I don't have any more ideas why it doesn't work for you. Looks like this issue can be closed. |
|
@Stivux I am now flashing USB disk and will try live iso OS8 also. On laptop UP5401EA with installed 7.1. I will let you know. |
|
@Stivux Unfortuntelly the same. Not replicated change of these values 0, 0, 233, 233. I am skipping some important step maybe but rather I think you have different .dsdt table because another laptop model or something like that. You can post here .dsdt if you want and we can compare touchpad block. |
|
|
|
EDIT: with different I2C registers I was wrong, I deleted these messages and others I did not compare. So is the same: Your block: Mine block: |
Sorry. I forgot to mention, that here How can we understand from dsdt what i2c register need we use? |
|
@Stivux Your command enabled the backlight of my NumberPad, so thank you for creating this feature issue! So the question is now how it works and could it be replacement of implemented i2c because some benefit gains. Could you summarize what you know in one post again, please? |
|
@Stivux Hm, read values after setting up I can not: But this command works: |
Sorry for the mystification. From DSDT we only know the address where we need to send something via i2c. In the
Values send to this address are sniffed on the windows via i2c sniffer tool (someone posted these values on the ubuntu issue page created for Numberpad, it was not sniffed by me) link to ubuntu issue https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1810183?comments=all |
# Part of code from https://github.com/vpelletier/python-ioctl-opt/blob/master/ioctl_opt/__init__.py
import fcntl # built-in
import ctypes # built-in
_IOC_NRBITS = 8
_IOC_TYPEBITS = 8
_IOC_SIZEBITS = 14
_IOC_DIRBITS = 2
_IOC_NRMASK = (1 << _IOC_NRBITS) - 1
_IOC_TYPEMASK = (1 << _IOC_TYPEBITS) - 1
_IOC_SIZEMASK = (1 << _IOC_SIZEBITS) - 1
_IOC_DIRMASK = (1 << _IOC_DIRBITS) - 1
_IOC_NRSHIFT = 0
_IOC_TYPESHIFT = _IOC_NRSHIFT + _IOC_NRBITS
_IOC_SIZESHIFT = _IOC_TYPESHIFT + _IOC_TYPEBITS
_IOC_DIRSHIFT = _IOC_SIZESHIFT + _IOC_SIZEBITS
IOC_NONE = 0
IOC_WRITE = 1
IOC_READ = 2
def IOC(dir, type, nr, size):
assert dir <= _IOC_DIRMASK, dir
assert type <= _IOC_TYPEMASK, type
assert nr <= _IOC_NRMASK, nr
assert size <= _IOC_SIZEMASK, size
return (dir << _IOC_DIRSHIFT) | (type << _IOC_TYPESHIFT) | (nr << _IOC_NRSHIFT) | (size << _IOC_SIZESHIFT)
HIDIOCSFEATURE = lambda len: IOC(IOC_WRITE|IOC_READ, ord('H'), 0x06, len)
HIDIOCGFEATURE = lambda len: IOC(IOC_WRITE|IOC_READ, ord('H'), 0x07, len)
file_handler = open("/dev/hidraw0", 'wb')
report = bytearray([0] * 256)
report[0] = 13 # report number
report_arr = (ctypes.c_char * len(report)).from_buffer(report)
report_size = fcntl.ioctl(file_handler, HIDIOCGFEATURE(len(report)), report_arr, True)
# after read report I can get current brightness at report[4]. I don't understand why you can't :(
report[1] = 112 # it is magic number now
report[2] = 3 # it is magic number now
report[3] = 1 # or 0 to disable led
report[4] = 81 # is 0x41 + 16. 16 is magic number now
report_arr = (ctypes.c_char * len(report)).from_buffer(report)
fcntl.ioctl(file_handler, HIDIOCSFEATURE(report_size), report_arr, True) # enable led with 0x41 brightnessThe advantage is that it works even if i2c_dev and i2c_smbus modules are blacklisted. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Short Description
I am using ASUS Zenbook UM3402YA (up5401ea layout) I noticed that brightness setting via i2c change report 13 feature of /dev/hidraw0
You can use https://github.com/hidutils/hid-feature to check your own.
It looks like:
13 │ Vendor Defined Page FF00 / Vendor Usage 0xc4 │ 8 │ 8..=15 │ 0..=255 │ 1 │ 112 │ 70
13 │ Vendor Defined Page FF00 / Vendor Usage 0xc4 │ 8 │ 16..=23 │ 0..=255 │ 1 │ 3 │ 03
13 │ Vendor Defined Page FF00 / Vendor Usage 0xc4 │ 8 │ 24..=31 │ 0..=255 │ 1 │ 0 │ 00
13 │ Vendor Defined Page FF00 / Vendor Usage 0xc4 │ 8 │ 32..=39 │ 0..=255 │ 1 │ 81 │ 51
When I turn numpad on, 0 goes into 1
When I change brightness level 81 is changing to other number (81 is 0x41 + 16)
Advantages of such a change are independence from i2c-dev and ability to recognize the latest brightness after reboot.
New dependencies
No response
Additional Info
No response
The text was updated successfully, but these errors were encountered: