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