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