skullnobrains
asked on
xorg without udev
hello
i am working on very tiny systems that do not feature udev or hal and trying to get xorg to work
for now, i have a working config based on xfree86-input-keyboard and xfree86-input mouse. and the following config file
... but i want something more generic than input-mouse and preferably without config files
i have struggled quite a lot with vmmouse and libinput to no avail
here are my issues :
1/ i could not figure out how to reference an inputclass instead of an inputdevice in serverlayout. this is probably documented... somewhere
2/ i am unsure which driver requires udev, hal and the likes. does anyone know ?
3/ i a wondering whether any of the input methods can work without the psmouse kernel module. i can deal with having that module ( either loaded or compiled in ) but it would be convenient to be able to test using a basic generic kernel with no modules.
4/ for some reason, if i do not declare a serverlayout, either xorg refuses to start, or it does start but does not load the input referenced in the packaged config files which all contain "inputclass" stanzas... anyone knows what i am missing ?
5/ using xwayland is an alternative i'd happily consider. does anyone know whether such issues are alleviated in wayland ?
6/ bonus question : do you know a reason to prefer using xorg's vesa driver over the framebuffer and the vesa driver in the kernel ? ( or the contrary )
i am testing in qemu should that matter
the distribution is NONE : this is a linux from scratch. it works like a charm for my current needs but i would like to allow to pack an additional mini-desktop
i am not interested in any comment that instruct me to use udev or hal or dbus or any such tools. NOT using them is a strict requirement here.
thanks a lot for any help you can provide
i am working on very tiny systems that do not feature udev or hal and trying to get xorg to work
for now, i have a working config based on xfree86-input-keyboard and xfree86-input mouse. and the following config file
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbLayout" "fr" # untested + we should be able to use environment
EndSection
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/input/mice" # mice event0 event1 & /dev/psaux input/event1
Option "ZAxisMapping" "4 5 6 7" # roller actions
EndSection
Section "ServerLayout"
Identifier "Layout[all]"
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
Option "AutoAddDevices" "off"
EndSection... but i want something more generic than input-mouse and preferably without config files
i have struggled quite a lot with vmmouse and libinput to no avail
here are my issues :
1/ i could not figure out how to reference an inputclass instead of an inputdevice in serverlayout. this is probably documented... somewhere
2/ i am unsure which driver requires udev, hal and the likes. does anyone know ?
3/ i a wondering whether any of the input methods can work without the psmouse kernel module. i can deal with having that module ( either loaded or compiled in ) but it would be convenient to be able to test using a basic generic kernel with no modules.
4/ for some reason, if i do not declare a serverlayout, either xorg refuses to start, or it does start but does not load the input referenced in the packaged config files which all contain "inputclass" stanzas... anyone knows what i am missing ?
5/ using xwayland is an alternative i'd happily consider. does anyone know whether such issues are alleviated in wayland ?
6/ bonus question : do you know a reason to prefer using xorg's vesa driver over the framebuffer and the vesa driver in the kernel ? ( or the contrary )
i am testing in qemu should that matter
the distribution is NONE : this is a linux from scratch. it works like a charm for my current needs but i would like to allow to pack an additional mini-desktop
i am not interested in any comment that instruct me to use udev or hal or dbus or any such tools. NOT using them is a strict requirement here.
thanks a lot for any help you can provide
ASKER
@david
i also mentioned
- this is Linux from scratch and not a distro. it is much smaller than even alpine in terms of disk size, memory footprint and whatever you may think of. it is also very specialized and READ ONLY through and through.
- xorg does NOT require udev. i mentioned i have a working config and provided said config.
- i mentionned i was testing in qemu. x86_64 should that matter.
this question is for people who already worked on xorg or xfree86 config files and drivers and/or linux from scratch.
i am not interested in any comment that instruct me to use udev or hal or dbus or any such tools. NOT using them is a strict requirement here.
i also mentioned
- this is Linux from scratch and not a distro. it is much smaller than even alpine in terms of disk size, memory footprint and whatever you may think of. it is also very specialized and READ ONLY through and through.
- xorg does NOT require udev. i mentioned i have a working config and provided said config.
- i mentionned i was testing in qemu. x86_64 should that matter.
this question is for people who already worked on xorg or xfree86 config files and drivers and/or linux from scratch.
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
I'll rephrase.
First step, determine if xorg will work without udev.
If udev is required, then you must use udev.
Research this first.
First step, determine if xorg will work without udev.
If udev is required, then you must use udev.
Research this first.
@David Favor: The OP already said he has a working config w/out udev
ASKER
hi Duncan. thanks a lot for your insight.
first some news : i managed to get wayland to work using udev-zero and devfs... still a work in progress but i assume this will allow me to work with a static devfs with just a bunch of preconfigured device nodes. unfortunately, wayland will not work without writing privileges on XDG_RUNTIME_DIR. i am still unsure i can circumvent that. either the answer is yes and i am ditching xorg entirely, or alternatively i am quite confident xorg will work with udev-zero and the libinput driver.
1/ i was actually using inputdevice sections : see above ;)
what i could not figure out is HOW to reference an inputclass in serverlayout
my guess at this point is the xorg config actually worked but both libinput and libev did not due to the lack of udev. i'll probably get a chance to check this afternoon.
2/ actually, libinput does require libudev (sigh). freebsd has a patched variant which has been more or less ported to linux.
3/ thanks. this aligns with my own conclusions. fortunately psmouse is a rather simple module with no dependencies. i was hoping i could just test by copying the generic kernel without modules from an existing machine. and totally wrong ;)
4/ yeah. i was trying to reference inputclass stanzas in serverlayout. and failed. anyway, this probably will work with a mostly zeroconf xorg but i'll post findings. ( see /1 ). afaik serverlayout is not required to start xorg.
5/ the answer is no : wayland requires libinput and does not feature any alternative driver for keyboard and mouse. i am currently using the framebuffer for the screen but expect to get drm to work if i continue going wayland which should be both lighter and more reactive.
6/ i did, but i have yet to test on various hardware. for now, the only thing i can tell is both work. i will let you know if i figure out something worthwhile. i am unsure i will since i do not exclude ditching xorg altogether and i do not really care about video performance in my current builds which target basic desktop usage. games are totally out of scope and video can be rendered directly by many players using a framebuffer, possibly through sdl much more efficiently anyway.
thanks again. i'll keep this thread open for a while in case anyone wants to chip in and so i can post future findings...
first some news : i managed to get wayland to work using udev-zero and devfs... still a work in progress but i assume this will allow me to work with a static devfs with just a bunch of preconfigured device nodes. unfortunately, wayland will not work without writing privileges on XDG_RUNTIME_DIR. i am still unsure i can circumvent that. either the answer is yes and i am ditching xorg entirely, or alternatively i am quite confident xorg will work with udev-zero and the libinput driver.
1/ i was actually using inputdevice sections : see above ;)
what i could not figure out is HOW to reference an inputclass in serverlayout
my guess at this point is the xorg config actually worked but both libinput and libev did not due to the lack of udev. i'll probably get a chance to check this afternoon.
2/ actually, libinput does require libudev (sigh). freebsd has a patched variant which has been more or less ported to linux.
3/ thanks. this aligns with my own conclusions. fortunately psmouse is a rather simple module with no dependencies. i was hoping i could just test by copying the generic kernel without modules from an existing machine. and totally wrong ;)
4/ yeah. i was trying to reference inputclass stanzas in serverlayout. and failed. anyway, this probably will work with a mostly zeroconf xorg but i'll post findings. ( see /1 ). afaik serverlayout is not required to start xorg.
5/ the answer is no : wayland requires libinput and does not feature any alternative driver for keyboard and mouse. i am currently using the framebuffer for the screen but expect to get drm to work if i continue going wayland which should be both lighter and more reactive.
6/ i did, but i have yet to test on various hardware. for now, the only thing i can tell is both work. i will let you know if i figure out something worthwhile. i am unsure i will since i do not exclude ditching xorg altogether and i do not really care about video performance in my current builds which target basic desktop usage. games are totally out of scope and video can be rendered directly by many players using a framebuffer, possibly through sdl much more efficiently anyway.
thanks again. i'll keep this thread open for a while in case anyone wants to chip in and so i can post future findings...
ASKER
UPDATE
xorg + libinput works like a charm with libudev-zero. no config required other than the config packaged with the libinput driver. i am unsure hot plugging works.
so the current status :
1/ i have still no idea how to reference inputclass in serverlayout
4/ there is no point in doing so unless you need xorg to handle multiple seats : the default config that comes with the libinput driver works without declaring a serverlayout
2/ libinput requires libudev. libudev-zero provides bindings that allow it to work without an actual udev.
no idea regarding libev.
if anyone knows of something less hacky, i'm all ears.
3/ psmouse is required
5/ wayland does not alleviate such concerns. on the contrary it ONLY features libinput.
6/ not sure yet. @duncan_roe suggests issues with the framebuffer but does not remember additional details.
xorg + libinput works like a charm with libudev-zero. no config required other than the config packaged with the libinput driver. i am unsure hot plugging works.
so the current status :
1/ i have still no idea how to reference inputclass in serverlayout
4/ there is no point in doing so unless you need xorg to handle multiple seats : the default config that comes with the libinput driver works without declaring a serverlayout
2/ libinput requires libudev. libudev-zero provides bindings that allow it to work without an actual udev.
no idea regarding libev.
if anyone knows of something less hacky, i'm all ears.
3/ psmouse is required
5/ wayland does not alleviate such concerns. on the contrary it ONLY features libinput.
6/ not sure yet. @duncan_roe suggests issues with the framebuffer but does not remember additional details.
ASKER
update for /6
one reason to use the framebuffer : it allows to run xorg as a dedicated non root user rather trivially by granting rights on the required device nodes : currently this works with /dev/tty0 (sigh), /dev/ttyXX (where XX is whichever tty xorg is bound to) and /dev/input/*.
there might be equivalent ways to run xvesa. i have not tried extensively.
i have yet to try xfbdev, microxwin, Y... alternatives
still hoping for /1
i am still hoping to understand how to achieve /1 as i would like to experiment on hybrid approaches using the kbd driver ( which i hope might work as non root without granting additional rights on all inputs ) and using libinput for the mouse. that said, i am unsure but if hotplugging a new mouse works natively, i see no benefit in using libinput at all.
my current system is not very optimised, runs a rather fat generic kernel and loads the filesystem in initrd. not the (sole) target but convenient for testing.
memory usage is about 87 megs : a little over 10 for the kernel, a little less than 60 for the initrd, and less than 20 for userland programs including xorg. without mounting the root as initrd, it should be usable with less than 50M or ram. maybe even less.
one reason to use the framebuffer : it allows to run xorg as a dedicated non root user rather trivially by granting rights on the required device nodes : currently this works with /dev/tty0 (sigh), /dev/ttyXX (where XX is whichever tty xorg is bound to) and /dev/input/*.
there might be equivalent ways to run xvesa. i have not tried extensively.
i have yet to try xfbdev, microxwin, Y... alternatives
still hoping for /1
i am still hoping to understand how to achieve /1 as i would like to experiment on hybrid approaches using the kbd driver ( which i hope might work as non root without granting additional rights on all inputs ) and using libinput for the mouse. that said, i am unsure but if hotplugging a new mouse works natively, i see no benefit in using libinput at all.
my current system is not very optimised, runs a rather fat generic kernel and loads the filesystem in initrd. not the (sole) target but convenient for testing.
memory usage is about 87 megs : a little over 10 for the kernel, a little less than 60 for the initrd, and less than 20 for userland programs including xorg. without mounting the root as initrd, it should be usable with less than 50M or ram. maybe even less.
I haven't messed with an xorg.conf for a while because xorg -config "just works" for me nowadays. Have you tried it on your system?
ASKER
hi Duncan... i sure did and i have multiple working configs including ones that allow to run as non root. but i sometimes need to hack with weird configs that -configure will most definitely not produce such as a libinput driven mouse with a kbd driven keyboard.
now i am trying to reach the following goals :
- run as non root user + spawn a minimal desktop as a different regular user
- minimize the bloat
- minimize the chmods in /dev and only allow ones i deem reasonably secure. namely i had rather NOT change the mode of /dev/input/* though /dev/input/mice,mouseX seem acceptable.
- if possible remove the need for a rw /tmp. it might be feasible to precreate the socket. i do not see a way to skip the lock file which is imho useless.
i am still unsure about sticking with xorg or not and really do not get why xorg is not capable to start as root and drop privileges afterwards. any insight regarding that matter would be welcome.
if the topic is of no further interest to you, please let me know and i will close the thread accepting your input as assisted answer so you get points while accepting a recap of your insight and my own findings as the most complete answer.
btw, regarding /6, xorg tries the framebuffer before the vesa driver so i would assume the xorg folks deem it is somehow "better". i have not experimented with modesetting KMS stuff which are supposed to provide 2D acceleration, but xorg tries those as a last resort. the drivers are small so my reasons bothering are partly due to the non-root requirement and partly for educational reasons.
now i am trying to reach the following goals :
- run as non root user + spawn a minimal desktop as a different regular user
- minimize the bloat
- minimize the chmods in /dev and only allow ones i deem reasonably secure. namely i had rather NOT change the mode of /dev/input/* though /dev/input/mice,mouseX seem acceptable.
- if possible remove the need for a rw /tmp. it might be feasible to precreate the socket. i do not see a way to skip the lock file which is imho useless.
i am still unsure about sticking with xorg or not and really do not get why xorg is not capable to start as root and drop privileges afterwards. any insight regarding that matter would be welcome.
if the topic is of no further interest to you, please let me know and i will close the thread accepting your input as assisted answer so you get points while accepting a recap of your insight and my own findings as the most complete answer.
btw, regarding /6, xorg tries the framebuffer before the vesa driver so i would assume the xorg folks deem it is somehow "better". i have not experimented with modesetting KMS stuff which are supposed to provide 2D acceleration, but xorg tries those as a last resort. the drivers are small so my reasons bothering are partly due to the non-root requirement and partly for educational reasons.
Hi skullnobrains - you are right I feel I have no more to contribute so please go ahead and close
Even BusyBox based Distros like Alpine (tiny disk footprint) require udev.
2) The udev subsystem is virtual so takes no measurable disk space.
Open in new window
Notice the usage is 0% of actual disk space.
There are some memory structures, which are also very small.
2) All the questions above are complex.
The first question is do any of the above questions actually matter.
If you require xorg running + xorg requires udev, then you must use udev.
3) If you're working on a "tiny system"... xorg is a memory hog, so likely won't work either.
4) If I were faced with this problem, I'd install Alpine... as-is... no attempted modifications... then install xorg... see if this worked.
Since you don't mention what "tiny system" might mean (small disk, small memory) difficult to guess.
You also don't mention the actual hardware you're running... which might be something exotic... where some custom Linux is required.
5) Start with Alpine first, then consider your next step.
6) For best comments, mention your hardware + Distro you've installed, as there's no real starting point to answer your questions from what's provided.