💾 Archived View for gemini.ctrl-c.club › ~phoebos › logs › kisslinux-2021-09-23.txt captured on 2021-12-17 at 13:26:06.
-=-=-=-=-=-=-
[2021-09-23T00:08:23Z] <ryoshu> hi
[2021-09-23T00:13:45Z] <ryoshu> I'm trying to compile libudev-zero
[2021-09-23T00:26:06Z] <acheam> okay
[2021-09-23T00:26:45Z] <acheam> testuser[m]: was that testuser you?
[2021-09-23T00:27:47Z] <acheam> you don't seem like the kind of person to be using pidgin in the wee hours of the morning
[2021-09-23T00:28:10Z] <dilyn> it's mid obvi
[2021-09-23T00:28:11Z] <acheam> oh it was GalaxyNova
[2021-09-23T00:28:36Z] <acheam> testuser[m]: you may want to register testuser with services
[2021-09-23T00:28:52Z] <acheam> dilyn: obvs
[2021-09-23T00:28:57Z] <acheam> good of him to check in on us
[2021-09-23T00:51:15Z] <GalaxyNova> oh yeah sorry for that
[2021-09-23T00:51:18Z] <GalaxyNova> I was testing something
[2021-09-23T00:51:28Z] <GalaxyNova> and called the user testuser, without thinking about it xD
[2021-09-23T00:52:07Z] <GalaxyNova> acheam: How could you tell it was pidgin
[2021-09-23T00:52:23Z] <ryoshu> GalaxyNova: is illiliti from Europe?
[2021-09-23T00:52:36Z] <GalaxyNova> They're from russia IIRC
[2021-09-23T00:52:53Z] <ryoshu> are they a team?
[2021-09-23T00:53:39Z] <GalaxyNova> what?
[2021-09-23T00:53:49Z] <ryoshu> you said 'they'
[2021-09-23T00:54:08Z] <ryoshu> I don't know association of illiliti
[2021-09-23T00:55:26Z] <ryoshu> $ file libudev.so.1
[2021-09-23T00:55:29Z] <ryoshu> libudev.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, for NetBSD 9.0, not stripped
[2021-09-23T00:55:46Z] <GalaxyNova> oh
[2021-09-23T00:55:51Z] <GalaxyNova> just gender neutral pronoun
[2021-09-23T00:56:08Z] <dilyn> ^ we don't know illiliti's identity :v
[2021-09-23T00:56:14Z] <dilyn> glad you got it to build ryoshu :O
[2021-09-23T00:56:54Z] <ryoshu> I had to stub linux/input and netlink
[2021-09-23T01:08:56Z] <GalaxyNova> also uh, has any one else experienced running firefox inside the guest causing qemu to segfault?
[2021-09-23T01:13:54Z] <ryoshu> I think I need evdev before proceeding with udev
[2021-09-23T01:20:37Z] <acheam> GalaxyNova: magic
[2021-09-23T01:33:27Z] <ryoshu> https://github.com/freebsd/freebsd-src/tree/8d73071c47ff1f911bdaec6356f37feb4e3b7cb5/sys/dev/evdev
[2021-09-23T01:58:31Z] <noocsharp> acme-client error messages on openbsd are almost worse than c++ compiler error messages
[2021-09-23T02:06:07Z] <GalaxyNova> impossible
[2021-09-23T02:10:03Z] <dilyn> are evdev and udev actually that related?
[2021-09-23T02:10:13Z] <dilyn> I thought they worked in conjunction to provide functionality for libinput
[2021-09-23T02:37:55Z] <acheam> noocsharp: how so?
[2021-09-23T02:38:02Z] <acheam> I've found -v to be plenty verbose to debug issues
[2021-09-23T02:38:13Z] <acheam> -vv does even more
[2021-09-23T02:47:13Z] <noocsharp> yeah, it took -vv for me to figure out what was wrong
[2021-09-23T02:47:34Z] <noocsharp> but it's still pretty obscure
[2021-09-23T03:12:20Z] <testuser[m]> Hi
[2021-09-23T03:16:10Z] <acheam> Hi!
[2021-09-23T03:24:25Z] <GalaxyNova[m]> Hi!
[2021-09-23T03:26:14Z] <GalaxyNova[m]> Matrix is cool
[2021-09-23T03:38:21Z] <testuser[m]> But you just said it's bloated lol
[2021-09-23T03:38:36Z] <GalaxyNova[m]> yeah... but that doesn't make it any less cool!
[2021-09-23T03:38:51Z] <GalaxyNova[m]> the fact that it's so easy to bridge services to it is amazing
[2021-09-23T03:38:57Z] <testuser[m]> Yeah
[2021-09-23T04:09:42Z] <acheam> omfg
[2021-09-23T04:09:54Z] <acheam> either mutt or claws mail is buggered out
[2021-09-23T04:09:55Z] <GalaxyNova> ?
[2021-09-23T04:10:01Z] <testuser[m]> wat
[2021-09-23T04:10:17Z] <acheam> because I just saw that many of my recent messages have been sent in like 16 parts, as I write the email
[2021-09-23T04:10:26Z] <GalaxyNova> hm
[2021-09-23T04:10:26Z] <acheam> like, its sending drafts as I write the email
[2021-09-23T04:10:30Z] <acheam> its probably claws
[2021-09-23T04:10:39Z] <GalaxyNova> testuser[m]: it seems like there's some significant latency in the matrix bridge
[2021-09-23T04:10:50Z] <GalaxyNova> is that normal?
[2021-09-23T04:10:57Z] <acheam> (luckily only the last couple emails, and nothing too too important)
[2021-09-23T04:11:06Z] <acheam> but how does that even happen
[2021-09-23T04:11:36Z] <GalaxyNova> =-O
[2021-09-23T04:11:47Z] <testuser[m]> Test
[2021-09-23T04:11:54Z] <acheam> GalaxyNova: UTC time right now is 5:11:53
[2021-09-23T04:11:54Z] <testuser[m]> its 0.5 second latency
[2021-09-23T04:12:06Z] <acheam> now 5:12:05
[2021-09-23T04:12:15Z] <acheam> 0.5sec isnt bad
[2021-09-23T04:12:20Z] <GalaxyNova> ah
[2021-09-23T04:12:23Z] <GalaxyNova> guess its fine
[2021-09-23T04:13:07Z] <GalaxyNova> I'll keep using IRC for the time being, but scrolling up the matrix channel is a lot easier than searching the logs
[2021-09-23T04:13:17Z] <acheam> just use a bouncer
[2021-09-23T04:13:42Z] <GalaxyNova> I don't really know how to set that up
[2021-09-23T04:13:56Z] <acheam> good opprotunity to learn then
[2021-09-23T04:14:24Z] <GalaxyNova> But why learn when you can just be lazy :P
[2021-09-23T04:14:50Z] <GalaxyNova> also since you're online
[2021-09-23T04:14:59Z] <GalaxyNova> I wanted to ask you how OpenBSD compared to KISS
[2021-09-23T04:15:16Z] <GalaxyNova> because I'm looking into switching to it
[2021-09-23T04:15:32Z] <acheam> very different
[2021-09-23T04:15:36Z] <acheam> just gotta try it for yourself
[2021-09-23T04:16:15Z] <GalaxyNova> do you think it's less "KISS"?
[2021-09-23T04:16:22Z] <acheam> yes
[2021-09-23T04:16:28Z] <acheam> more bloat
[2021-09-23T04:17:20Z] <GalaxyNova> :-/
[2021-09-23T04:18:46Z] <testuser[m]> but its sekure
[2021-09-23T04:23:26Z] <GalaxyNova> well I guess it's not necessarily "bloated", just includes lots of programs by default
[2021-09-23T04:23:39Z] <GalaxyNova> which as far as I understand are more lightweight than the alternatives
[2021-09-23T04:40:41Z] <GalaxyNova> acheam: What did you find OpenBSD did better than linux
[2021-09-23T06:28:20Z] <GalaxyNova> Someone fix / adopt the qemu package
[2021-09-23T06:28:43Z] <GalaxyNova> it no longer builds and the maintainer is inactive
[2021-09-23T06:29:18Z] <GalaxyNova> Also something must be wrong with the patches because I've encountered a bunch of random segfaults for no reason
[2021-09-23T06:37:59Z] <testuser[m]> why dont you adopt it
[2021-09-23T06:39:05Z] <GalaxyNova> because I'm too dumb to maintain the patches
[2021-09-23T06:39:26Z] <GalaxyNova> and the patches broke in the new release
[2021-09-23T06:41:20Z] <testuser[m]> then learn how to fix them
[2021-09-23T06:43:10Z] <GalaxyNova> perhaps
[2021-09-23T06:43:54Z] <testuser[m]> you just need to apply the patch, look at the .rej and apply the failed patch manually
[2021-09-23T06:49:09Z] <GalaxyNova> that's the easy part
[2021-09-23T06:49:21Z] <GalaxyNova> the hard part is finding our why tf qemu crashes when I open firefox in the guest
[2021-09-23T06:49:39Z] <GalaxyNova> I've run it through gdb multiple times and even built it in debug mode but no luck
[2021-09-23T06:49:42Z] <GalaxyNova> just garbage backtrace
[2021-09-23T06:50:05Z] <testuser[m]> show
[2021-09-23T06:50:12Z] <testuser[m]> does it just say "??"
[2021-09-23T06:50:19Z] <GalaxyNova> just random memory addresses
[2021-09-23T06:50:23Z] <testuser[m]> build with -g3 and set KISS_STRIP=0
[2021-09-23T06:50:23Z] <GalaxyNova> and question marks
[2021-09-23T06:50:26Z] <testuser[m]> show
[2021-09-23T06:50:30Z] <GalaxyNova> alright
[2021-09-23T06:50:31Z] <GalaxyNova> later
[2021-09-23T06:50:34Z] <GalaxyNova> gtg
[2021-09-23T06:50:37Z] <testuser[m]> ok
[2021-09-23T08:46:14Z] <testuser[m]> dilyn: have you had this issue in chromium where half of the clickable stuff just locks up
[2021-09-23T08:46:24Z] <testuser[m]> like you cant click the address bar or switch tabs via clicking
[2021-09-23T08:46:32Z] <testuser[m]> but with keyboard it works
[2021-09-23T09:20:55Z] <ryoshu> hello
[2021-09-23T09:21:18Z] <testuser[m]> hi
[2021-09-23T09:35:37Z] <phoebos> acheam: i think i noticed something like that happening with me, but I don't think my emails were actually sent like that
[2021-09-23T10:24:14Z] <ryoshu> illiliti i think the next step is to implement evdev
[2021-09-23T10:26:51Z] <ryoshu> i got udev-zero to build
[2021-09-23T10:27:04Z] <ryoshu> stubbing netlink and linux input
[2021-09-23T10:27:40Z] <ryoshu> i still dont know how to get netlink implemented
[2021-09-23T10:42:48Z] <illiliti> you also need linuxish sysfs
[2021-09-23T10:42:52Z] <illiliti> libudev-zero uses it for enumeration/input detection
[2021-09-23T10:45:34Z] <illiliti> anyway i think what are you doing is bad idea in general
[2021-09-23T10:45:57Z] <illiliti> libudev-zero highly relies on linux features
[2021-09-23T10:46:54Z] <illiliti> i think it's better to implement libudev API for netbsd from scratch
[2021-09-23T10:47:28Z] <illiliti> see freebsd's libudev-devd
[2021-09-23T11:00:14Z] <illiliti> to be clear, you can use libudev-zero as a base but you still need to implement basic stuff like enumeration and monitoring from scratch
[2021-09-23T11:18:42Z] <ryoshu> yes
[2021-09-23T11:18:56Z] <ryoshu> i need to implement these features
[2021-09-23T11:19:11Z] <ryoshu> i dont know as of today equivalents
[2021-09-23T11:24:58Z] <illiliti> as far as i understand, /dev/drvctl should be enough to implement enumeration and monitoring
[2021-09-23T11:25:15Z] <illiliti> DRVLISTDEV for enumeration
[2021-09-23T11:25:20Z] <illiliti> DRVGETEVENT for monitoring
[2021-09-23T11:28:38Z] <ryoshu> I will give it a try
[2021-09-23T12:55:53Z] <f1> hi
[2021-09-23T13:11:51Z] <testuser[m]> Hi
[2021-09-23T14:00:28Z] <dilyn> testuser[m]: no I haven't; but those black box graphical glitches are back :|
[2021-09-23T14:00:48Z] <dilyn> GalaxyNova: I have patches that work with the latest release; I don't experience any of the problems you are tho
[2021-09-23T14:45:10Z] <ryoshu> illiliti do I understand correctly that pressed input clicks are processed through libudev
[2021-09-23T14:49:31Z] <illiliti> no
[2021-09-23T14:49:55Z] <illiliti> libudev only monitors device state change
[2021-09-23T14:51:08Z] <illiliti> input clicks are processed through libinput on linux
[2021-09-23T14:51:48Z] <illiliti> libinput uses libudev to get input devices
[2021-09-23T14:52:46Z] <ryoshu> i see
[2021-09-23T14:53:17Z] <ryoshu> i am processing it slowly
[2021-09-23T14:53:48Z] <ryoshu> then possibly drvctl can do everything
[2021-09-23T15:13:15Z] <ryoshu> am i right?
[2021-09-23T15:17:42Z] <illiliti> i guess so
[2021-09-23T15:57:32Z] <ryoshu> thank you
[2021-09-23T17:10:01Z] <noocsharp> wow, replacing eudev with mdevd was suprisingly painless
[2021-09-23T17:12:35Z] <ryoshu> what id mdevd
[2021-09-23T17:14:25Z] <noocsharp> device manager by skarnet
[2021-09-23T17:39:42Z] <soliwilos> If you use mdevd master it can also hotplug/communicate with libudev-zero which is really nice.
[2021-09-23T17:42:12Z] <soliwilos> Though I guess the git commit extra/mdevd uses is probably that particular feature.
[2021-09-23T18:16:58Z] <ryoshu> illiliti: https://susepaste.org/77258606
[2021-09-23T18:18:06Z] <noocsharp> yeah, hotplugging seems to be working fine
[2021-09-23T18:20:00Z] <illiliti> ryoshu: what does this mean?
[2021-09-23T18:24:49Z] <ryoshu> illiliti: 1 usbdevs open("/dev/usb0", 0, 0x7f7fff333df9) Err#13 EACCES
[2021-09-23T18:24:59Z] <ryoshu> I wonder whether I can list USB devices as user
[2021-09-23T18:25:03Z] <ryoshu> how about linux case?
[2021-09-23T18:27:16Z] <illiliti> linux provides sysfs for that
[2021-09-23T18:27:20Z] <illiliti> /sys/bus/usb/devices
[2021-09-23T18:28:04Z] <illiliti> why do you need access to /dev/usb*? DRVLISTDEV isn't enough?
[2021-09-23T18:29:14Z] <ryoshu> I'm experimenting
[2021-09-23T18:29:47Z] <illiliti> ah
[2021-09-23T18:30:07Z] <ryoshu> I'm learning this interface.
[2021-09-23T18:31:38Z] <ryoshu> https://nxr.netbsd.org/xref/src/usr.sbin/usbdevs/usbdevs.c
[2021-09-23T18:34:50Z] <illiliti> it uses DRVLISTDEV call underhood
[2021-09-23T18:34:56Z] <illiliti> https://nxr.netbsd.org/xref/src/usr.sbin/usbdevs/usbdevs.c#349
[2021-09-23T18:36:16Z] <ryoshu> Yes, I'm experimenting. I need time.
[2021-09-23T18:36:33Z] <illiliti> ok
[2021-09-23T19:48:26Z] <ryoshu> illiliti: unless I am wrong, drvctl does not show detailed list of devices
[2021-09-23T19:48:40Z] <ryoshu> it is more for listing device drivers in the system
[2021-09-23T19:49:26Z] <ryoshu> illiliti: https://susepaste.org/35911078
[2021-09-23T19:51:02Z] <ryoshu> so in order to list USB devices (vendor:product), I need to read /dev/usb*
[2021-09-23T19:51:33Z] <ryoshu> and I need to be a root
[2021-09-23T19:52:02Z] <illiliti> it shows parent devices and their childs
[2021-09-23T19:52:06Z] <illiliti> it's good enough(i think) to implement enumerate stuff
[2021-09-23T19:52:46Z] <ryoshu> we get some opaque idea that some device driver is there
[2021-09-23T19:52:55Z] <ryoshu> without details of the device
[2021-09-23T19:53:08Z] <illiliti> child devices are represented in /dev
[2021-09-23T19:53:16Z] <ryoshu> yes
[2021-09-23T19:54:42Z] <ryoshu> udev_monitor_filter_add_match_subsystem_devtype(mon, "input", NULL);
[2021-09-23T19:54:52Z] <ryoshu> how would you implement such function?
[2021-09-23T19:56:16Z] <illiliti> strncmp(dev, "wskbd", 5)
[2021-09-23T19:56:25Z] <illiliti> same for wsmouse
[2021-09-23T19:57:29Z] <illiliti> i.e if dev starts with wskbd or wsmouse, then mark it as input
[2021-09-23T19:59:03Z] <illiliti> don't bother with devtype
[2021-09-23T19:59:31Z] <illiliti> it's usually useless
[2021-09-23T20:01:45Z] <illiliti> ryoshu: does netbsd support joysticks/gamepads?
[2021-09-23T20:01:55Z] <ryoshu> yes
[2021-09-23T20:02:14Z] <ryoshu> joy(4)
[2021-09-23T20:02:18Z] <ryoshu> maybe others for modern stuff
[2021-09-23T20:02:26Z] <ryoshu> /dev/joy
[2021-09-23T20:02:49Z] <illiliti> good
[2021-09-23T20:03:19Z] <illiliti> mark joy as input device too
[2021-09-23T20:04:30Z] <ryoshu> systemd man pages are quite stub
[2021-09-23T20:04:38Z] <ryoshu> https://www.freedesktop.org/software/systemd/man/udev_device_get_action.html
[2021-09-23T20:04:47Z] <illiliti> yeah
[2021-09-23T20:04:58Z] <illiliti> totally useless shit
[2021-09-23T20:05:10Z] <ryoshu> I'm confused what is really wanted and whether I can deliver it
[2021-09-23T20:06:48Z] <illiliti> i don't know what events netbsd support. On linux there's add, remove, change, bind, unbind, ...
[2021-09-23T20:07:26Z] <illiliti> add and remove are self-explanatory
[2021-09-23T20:11:57Z] <illiliti> the rest is linux specific
[2021-09-23T20:12:06Z] <ryoshu> "device-attach" and "device-detach"
[2021-09-23T20:12:14Z] <ryoshu> only these 2
[2021-09-23T20:13:40Z] <illiliti> make aliases
[2021-09-23T20:13:43Z] <illiliti> device-attach == add
[2021-09-23T20:13:44Z] <illiliti> device-detach == remove
[2021-09-23T20:16:40Z] <ryoshu> udev_device_get_devnode(dev) returns like /dev/wskbd0, am I right?
[2021-09-23T20:16:56Z] <illiliti> yep
[2021-09-23T20:17:04Z] <ryoshu> udev_device_get_subsystem() how about this?
[2021-09-23T20:17:21Z] <ryoshu> I guess that syspath is /sys thing so linux specific
[2021-09-23T20:17:59Z] <illiliti> subsystem is a class of device. e.g "input"
[2021-09-23T20:19:54Z] <illiliti> syspath is tricky to implement when you don't have actual sysfs
[2021-09-23T20:20:37Z] <ryoshu> is it essential for something?
[2021-09-23T20:20:53Z] <ryoshu> I just plan to remove linux specific functions from API
[2021-09-23T20:20:59Z] <illiliti> https://github.com/FreeBSDDesktop/libudev-devd/ << this might be helpful
[2021-09-23T20:21:34Z] <illiliti> udev_enumerate_get_list_entry() returns linked list of syspaths
[2021-09-23T20:23:15Z] <illiliti> looks like libudev-devd just returns devnodes
[2021-09-23T20:23:28Z] <ryoshu> struct udev_list_entry
[2021-09-23T20:23:57Z] <ryoshu> I think and hope it's abstracted enough to avoid syspath
[2021-09-23T20:24:25Z] <ryoshu> udev_monitor_new_from_netlink() I plan to rename to udev_monitor_new_from_drvctl() :)
[2021-09-23T20:24:34Z] <ryoshu> or just udev_monitor_new()
[2021-09-23T20:25:07Z] <ryoshu> it might need some patching in 3rd party but at least it shouldn't look so bad
[2021-09-23T20:25:46Z] <illiliti> apps that expect original udev api will not work if you rename these functions
[2021-09-23T20:26:07Z] <illiliti> libudev-devd managed to do it without renaming. i think you can too
[2021-09-23T20:27:15Z] <ryoshu> we can manage, like max 10 popular programs use API anyway
[2021-09-23T20:28:00Z] <ryoshu> as a next step we can evaluate your API that is more portable
[2021-09-23T20:28:09Z] <ryoshu> and port these 10 programs to it
[2021-09-23T20:29:18Z] <illiliti> yeah, i plan to convince mainstream apps to use new lib
[2021-09-23T20:29:28Z] <illiliti> because libudev is too linux-specific
[2021-09-23T20:32:57Z] <ryoshu> using sys/sysmacros.h and stuff are linux-specific too, in libudev.h
[2021-09-23T20:33:12Z] <ryoshu> so patch is necessary anyway
[2021-09-23T20:34:03Z] <illiliti> yeah
[2021-09-23T20:35:59Z] <illiliti> systemd basically sabotaged the whole *nix ecosystem by introducing libudev
[2021-09-23T20:36:07Z] <ryoshu> why is your header called udev.h and not libudev.h?
[2021-09-23T20:36:34Z] <ryoshu> cp -f udev.h ${DESTDIR}${INCLUDEDIR}/libudev.h
[2021-09-23T20:36:40Z] <ryoshu> ok, I can see it's installed as libudev.h
[2021-09-23T20:37:34Z] <ryoshu> to avoid pulling libudev gpl from system by an accident in the build of udev-zero?
[2021-09-23T20:39:22Z] <illiliti> yes
[2021-09-23T20:43:58Z] <illiliti> ryoshu: do you know how to implement get_parent() ?
[2021-09-23T20:44:34Z] <ryoshu> what is the expected result?
[2021-09-23T20:44:55Z] <ryoshu> pckbc2
[2021-09-23T20:44:55Z] <ryoshu> pckbd0
[2021-09-23T20:44:55Z] <ryoshu> wskbd0
[2021-09-23T20:45:04Z] <ryoshu> get_parent(wskbd0) -> pckbd0 ?
[2021-09-23T20:45:15Z] <illiliti> this
[2021-09-23T20:46:01Z] <illiliti> i think this is the only way to implement this function
[2021-09-23T20:46:27Z] <ryoshu> const char *udev_device_get_sysname(struct udev_device *udev_device);
[2021-09-23T20:46:29Z] <ryoshu> const char *udev_device_get_sysnum(struct udev_device *udev_device);
[2021-09-23T20:46:32Z] <ryoshu> is this related to /sys ?
[2021-09-23T20:46:39Z] <illiliti> yep
[2021-09-23T20:46:54Z] <ryoshu> unsigned long long udev_device_get_usec_since_initialized(struct udev_device *udev_device); hmm, I don't think I have this data
[2021-09-23T20:46:57Z] <ryoshu> anywhere
[2021-09-23T20:47:00Z] <ryoshu> except dmesg
[2021-09-23T20:47:07Z] <illiliti> forget about this
[2021-09-23T20:47:15Z] <illiliti> it's unused
[2021-09-23T20:47:23Z] <illiliti> just stub it
[2021-09-23T20:47:34Z] <ryoshu> I plan to trim unapplicable calls
[2021-09-23T20:48:43Z] <illiliti> why? just leave them stubbed
[2021-09-23T20:49:33Z] <ryoshu> if something uses it, I/we can find out
[2021-09-23T20:49:44Z] <illiliti> ok
[2021-09-23T20:49:48Z] <ryoshu> instead of silently currupting things
[2021-09-23T20:49:48Z] <illiliti> also, you can implement sysname/sysnum by parsing devnode
[2021-09-23T20:50:28Z] <illiliti> devnode == /dev/wskbd0, sysname == wskbd, sysnum == 0
[2021-09-23T20:50:56Z] <ryoshu> devpath=?
[2021-09-23T20:51:08Z] <ryoshu> udev_device_get_seqnum?
[2021-09-23T20:51:15Z] <ryoshu> udev_device_get_devtype?
[2021-09-23T20:51:56Z] <illiliti> devpath is syspath without /sys
[2021-09-23T20:52:07Z] <illiliti> seqnum is a number of event
[2021-09-23T20:52:31Z] <illiliti> devtype is linux-specific and usually unused
[2021-09-23T20:52:32Z] <ryoshu> sorry for asking such questions, docs are not meaningful enough
[2021-09-23T20:52:47Z] <illiliti> yeah, i know :)
[2021-09-23T20:53:06Z] <ryoshu> I don't have linux handy, but printing results for:
[2021-09-23T20:53:12Z] <ryoshu> udev_device
[2021-09-23T20:53:18Z] <ryoshu> and sharing would be helpful
[2021-09-23T20:53:30Z] <ryoshu> usb_device*()
[2021-09-23T20:53:35Z] <ryoshu> udev_device*()
[2021-09-23T20:53:48Z] <illiliti> will do
[2021-09-23T21:01:05Z] <ryoshu> what is SEQNUM?
[2021-09-23T21:01:14Z] <ryoshu> I get SUBSYSTEM and ACTION
[2021-09-23T21:01:19Z] <ryoshu> but not SEQNUM
[2021-09-23T21:01:24Z] <ryoshu> like 2 for wskbd2 ?
[2021-09-23T21:02:15Z] <illiliti> no no
[2021-09-23T21:03:16Z] <illiliti> SEQNUM is defined when device was received via hotplug event
[2021-09-23T21:03:37Z] <ryoshu> what does it say?
[2021-09-23T21:04:34Z] <ryoshu> I can skip it I think
[2021-09-23T21:04:42Z] <ryoshu> grep.app shows no real users anyway
[2021-09-23T21:05:24Z] <illiliti> yes, it's linux specific feature
[2021-09-23T21:05:31Z] <illiliti> it's intended to synchronize(?) events
[2021-09-23T21:07:15Z] <illiliti> https://github.com/mirror/busybox/blob/master/util-linux/mdev.c#L108-L110
[2021-09-23T21:07:57Z] <illiliti> i'm pretty sure nowadays it's not needed
[2021-09-23T21:09:06Z] <illiliti> linux can synchronize uevents without help from userspace
[2021-09-23T21:10:15Z] <ryoshu> what was devtype?
[2021-09-23T21:10:43Z] <ryoshu> https://github.com/mirror/busybox/blob/master/util-linux/mdev.c#L165
[2021-09-23T21:10:48Z] <ryoshu> OK, I think I can read from here
[2021-09-23T21:11:23Z] <illiliti> https://termbin.com/hcv1
[2021-09-23T21:12:12Z] <ryoshu> thank you!
[2021-09-23T21:12:22Z] <ryoshu> devtype is possible to implement
[2021-09-23T21:13:01Z] <ryoshu> udev_device_get_driver() seems interesting as it maps for wskbd0 to wskbd
[2021-09-23T21:13:03Z] <ryoshu> and similar
[2021-09-23T21:13:30Z] <illiliti> devtype is rarely used
[2021-09-23T21:13:39Z] <illiliti> don't bother with it
[2021-09-23T21:14:10Z] <illiliti> get_driver is rarely used too
[2021-09-23T21:14:14Z] <ryoshu> I guess udev devs just designed their API by dumping raw data from the kernel as-is
[2021-09-23T21:14:56Z] <ryoshu> and like 50% or more seems not that useful
[2021-09-23T21:18:45Z] <illiliti> yeah, it's badly designed
[2021-09-23T21:20:54Z] <ryoshu> udev_set_log_priority and udev_get_log_priority + udev_set_log_fn can be dropped too
[2021-09-23T21:21:04Z] <illiliti> https://termbin.com/0cno
[2021-09-23T21:21:42Z] <illiliti> https://termbin.com/t6i7
[2021-09-23T21:22:28Z] <ryoshu> udev_device_get_properties_list_entry - udev_device_set_sysattr_value how about these?
[2021-09-23T21:22:31Z] <ryoshu> thank you!
[2021-09-23T21:22:56Z] <illiliti> udev_device_get_properties_list_entry returns linked list of internal properties
[2021-09-23T21:23:15Z] <illiliti> udev_device_set_sysattr_value is linux-specific
[2021-09-23T21:23:23Z] <illiliti> and rarely used
[2021-09-23T21:23:41Z] <illiliti> it writes new value to sysfs attribute
[2021-09-23T21:24:32Z] <ryoshu> ah
[2021-09-23T21:27:35Z] <illiliti> is there a way to distinguish mouse and touchpad on netbsd?
[2021-09-23T21:29:09Z] <ryoshu> looking
[2021-09-23T21:35:45Z] <ryoshu> illiliti: unless I miss something, there is no way with wscons/wsmouse
[2021-09-23T21:35:53Z] <ryoshu> but I want evdev anyway
[2021-09-23T21:40:04Z] <illiliti> wscons is too generic, i see
[2021-09-23T21:40:28Z] <ryoshu> is this a problem for udev?
[2021-09-23T21:41:28Z] <illiliti> libinput distinguishes mouse and touchpad through libudev
[2021-09-23T21:41:40Z] <ryoshu> how?
[2021-09-23T21:41:45Z] <ryoshu> SUBSYSTEM?
[2021-09-23T21:42:31Z] <illiliti> https://github.com/illiliti/libudev-zero/blob/master/udev_device.c#L397-L506
[2021-09-23T21:43:08Z] <illiliti> ID_INPUT_TOUCHPAD
[2021-09-23T21:43:13Z] <illiliti> ID_INPUT_MOUSE
[2021-09-23T21:44:35Z] <illiliti> it's not a problem if you want to implement evdev
[2021-09-23T21:45:27Z] <illiliti> anyway you have to because libinput depends on evdev
[2021-09-23T21:47:18Z] <ryoshu> so we call e.g. udev_device_get_property_value(u, "ID_INPUT_MOUSE") and receive "1"
[2021-09-23T21:47:21Z] <ryoshu> right?
[2021-09-23T21:47:28Z] <ryoshu> what are:
[2021-09-23T21:47:29Z] <ryoshu> struct udev_list_entry *udev_device_get_properties_list_entry(struct udev_device *udev_device);
[2021-09-23T21:47:32Z] <ryoshu> struct udev_list_entry *udev_device_get_tags_list_entry(struct udev_device *udev_device);
[2021-09-23T21:48:37Z] <illiliti> udev_device_get_properties_list_entry used to iterate over properties
[2021-09-23T21:48:57Z] <illiliti> udev_device_get_tags_list_entry is udev-specific
[2021-09-23T21:49:12Z] <ryoshu> I don't get tags vs properties
[2021-09-23T21:49:51Z] <ryoshu> udev_device_get_tags_list_entry is not implemented
[2021-09-23T21:50:02Z] <ryoshu> whatever that is, drop
[2021-09-23T21:50:08Z] <illiliti> tags specified via udev rules
[2021-09-23T21:50:43Z] <ryoshu> hwdb?
[2021-09-23T21:50:48Z] <illiliti> no
[2021-09-23T21:50:51Z] <ryoshu> or something else
[2021-09-23T21:50:52Z] <ryoshu> ok
[2021-09-23T21:53:31Z] <ryoshu> udev_device_new_from_environment is interesting, but unimplemented
[2021-09-23T21:53:38Z] <ryoshu> so drop :)
[2021-09-23T21:53:54Z] <ryoshu> I counter check users in grep.app, but there are usually none or 1
[2021-09-23T21:54:27Z] <ryoshu> or very few, but not crucial
[2021-09-23T21:55:16Z] <illiliti> yep
[2021-09-23T21:56:18Z] <ryoshu> udev_device_new_from_device_id unimplemented too
[2021-09-23T21:57:25Z] <illiliti> just try to implement everything what libudev-zero has
[2021-09-23T21:58:03Z] <illiliti> and you'll be good
[2021-09-23T22:13:19Z] <ryoshu> udev_device_get_parent_with_subsystem_devtype I don't get this
[2021-09-23T22:13:48Z] <ryoshu> does it look for parent->greyparent->etc?
[2021-09-23T22:14:02Z] <illiliti> yes
[2021-09-23T22:14:32Z] <ryoshu> I still want devtype
[2021-09-23T22:14:51Z] <illiliti> you don't need it
[2021-09-23T22:15:14Z] <illiliti> it's useless and too linux-specific
[2021-09-23T22:15:19Z] <ryoshu> but udev_device_get_parent_with_subsystem_devtype takes it?
[2021-09-23T22:15:41Z] <illiliti> it's optional
[2021-09-23T22:17:01Z] <ryoshu> anyway I think that code using udev_device_get_parent_with_subsystem_devtype assumes linux hierarchy
[2021-09-23T22:17:07Z] <ryoshu> so it's waste of time to emulate it
[2021-09-23T22:17:58Z] <illiliti> maybe
[2021-09-23T22:18:40Z] <illiliti> many apps uses it though
[2021-09-23T22:19:26Z] <ryoshu> yes, instead of emulating linux kernel internals here, better to adapt users IMO
[2021-09-23T22:20:03Z] <illiliti> agree
[2021-09-23T22:49:09Z] <ryoshu> udev_device_unref.. returns NULL
[2021-09-23T22:49:21Z] <ryoshu> always
[2021-09-23T23:22:17Z] <ryoshu> is there a subsystem value for unknown/unrecognized?
[2021-09-23T23:23:18Z] <illiliti> NULL
[2021-09-23T23:25:41Z] <illiliti> what devices has unknown subsystem?
[2021-09-23T23:26:06Z] <illiliti> i'm pretty sure any device has subsystem
[2021-09-23T23:28:44Z] <ryoshu> I want to get INPUT work nicely where others return temporarily UNKNOWN
[2021-09-23T23:29:04Z] <ryoshu> before I can go over all the drivers
[2021-09-23T23:30:20Z] <illiliti> ok
[2021-09-23T23:39:37Z] <illiliti> have you implemented evdev yet?
[2021-09-23T23:40:51Z] <ryoshu> not yet!
[2021-09-23T23:40:52Z] <ryoshu> O
[2021-09-23T23:40:59Z] <ryoshu> I'm working on libudev
[2021-09-23T23:42:07Z] <ryoshu> silly question, once a device is detached, is struct udev_device valid?
[2021-09-23T23:42:13Z] <ryoshu> removed
[2021-09-23T23:42:25Z] <illiliti> yes
[2021-09-23T23:42:34Z] <ryoshu> is it cleaned at some point?
[2021-09-23T23:43:05Z] <illiliti> you need to destroy it manually
[2021-09-23T23:43:09Z] <illiliti> udev_device_unref
[2021-09-23T23:43:50Z] <ryoshu> how about detach->attach sequence, can I get two udev_devices with almost the same content?