# smdev ebuilds and guide for switching from udev

## defer-

usmdev[0] is device manager for linux. I maintain ebuilds[1] for smdev in my overlay[2]. The ebuilds contains initscript for gentoo and supports savedconfig. It's easy to switch from udev.

I have working sound, wlan, touchpad, trackpoint, keyboard and opengl with default smdev config and the initscript i wrote for the ebuild..

[0] http://git.suckless.org/smdev/

[1] https://github.com/causes-/causelay/tree/master/sys-fs/smdev

[2] https://github.com/causes-/causelay

Migrate from udev

Disable udev dependent features

evdev depends to udev so you should use mouse and keyboard/kbd drivers instead.

Disable udev USE flag and evdev x.org driver. 

/etc/portage/make.conf

```
USE="-udev"

INPUT_DEVICES="synaptics keyboard mouse"
```

Rebuild world.

```
emerge -uavDN @world
```

Configure X.Org to use mouse and keyboard/kbd drivers instead of evdev

You have to change configs to use mouse/kbd instead of evdev and "InputDevice" instead of "InputClass".

Example x.org configs for smdev.

/etc/X11/xorg.conf.d/10-keyboard.conf

```
Section "InputDevice"

        identifier      "keyboard0"

        driver          "kbd"

        option          "AutoServerLayout" "on"

        option          "XkbRules" "xorg"

        option          "XkbModel" "pc105"

        option          "XkbLayout" "fi"

EndSection
```

/etc/X11/xorg.conf.d/20-synaptics.conf

```
Section "InputDevice"

        identifier      "touchpad0"

        driver          "synaptics"

        option          "AutoServerLayout" "on"

        Option "HorizTwoFingerScroll" "1"

        Option "HorizHysteresis" "50"

        Option "VertHysteresis" "50"

EndSection
```

/etc/X11/xorg.conf.d/30-mouse.conf

```
Section "InputDevice"

        identifier      "Mouse0"

        driver          "mouse"

        option          "AutoServerLayout"      "on"

        option  "device"        "/dev/input/mice"

EndSection
```

add users to tty group

```
gpasswd -a <USER> tty
```

add smdev to sysinit runlevel

```
rc-update del udev sysinit

rc-update del udev-mount sysinit

rc-update add smdev sysinit
```

reboot

Now you are ready to reboot. After checking everything is working you can unmerge udev if you want.  :Smile: 

Acknowledgements

I got much help for configuring X.Org from slashbeast's repository.

https://github.com/slashbeast/mdev-like-a-boss

----------

## krinn

Is there a real reason to block users from using xorg with udev flag and prevent evdev presence?

----------

## khayyam

defer- ... good work. I'm currently using mdev (in conjunction with mdev-like-a-boss) so probably no reason to switch. Some feedback and a question, you should probably add virtual/dev-manager to the overlay and add sys-fs/smdev as a provider. Does smdev support /etc/mactab?

 *krinn wrote:*   

> Is there a real reason to block users from using xorg with udev flag and prevent evdev presence?

 

evdev doesn't work unless {,e}udev is running, so if you want to use {,s}mdev then obviously you loose that functionality.

best ... khay

----------

## krinn

My point is :

If there are incompatibilities to have them both, then i understand the block.

But if the block is just there, because you cannot use evdev with smdev that's limiting people for no reason.

Remove the block, add a message to explicitly tell people to not use evdev with smdev.

But this will allow anyone to have both install and start/stop the one it wish with or without evdev depending on the one in use.

It only said evdev depend on udev, it's different than "evdev will prevent smdev working".

You can have evdev and keyboard/mouse and use the one you need.

----------

## khayyam

 *krinn wrote:*   

> It only said evdev depend on udev, it's different than "evdev will prevent smdev working".
> 
> You can have evdev and keyboard/mouse and use the one you need.

 

krinn ... perhaps I wasn't clear, if the udev useflag is enabled on xorg-server then it will expect udev to be running, if {,s}mdev is running as device-manager then X11 will fail. evdev is needed for udev, but it serves no purpose when using {,s}mdev, and as there is no way to switch (at least not without re-compilation) then obviously the choice is such that one or other device-manager need be configured, and so the udev useflag disabled, evdev removed from INPUT_DEVICES, etc. {,e}udev can be installed if need be, but those things which expect udev to be running won't work, and so the useflag needs to be disabled.

best ... khay

----------

## krinn

That's not what i see here :

I have /etc/init.d/udev stop and restart xdm and it just works, evdev is happy running (of course udev is stopped but it has create the devices already and the devtmpfs is mount with them).

The only problem : if i unplug the mouse and replug the mouse... nothing

So without udev, evdev manage to still works when xorg is starting if the devs entries are there.

To me, evdev runtime dependency on udev is for unplug/plug devices while running xorg, but it doesn't need it at all to just start it.

And everyone knows already xorg will works without evdev but keyboard/mouse, something anyone can select with a proper xorg.conf

So i don't see any problem with someone using xorg[udev] flag and switching its xorg.conf with evdev and keyboard/mouse depending if it run udev or smdev.

I'm not really in mood to actually test, but if smdev create the needed devices for evdev to detect the devices attach to it, i'm "sure" evdev will also happy works and people might just use smdev with evdev (while of course lacking the plug/unplug devices in xorg).

I'm not really feeling that good, because generally if you say something and other something else ; is a good hint you are wrong  :Smile: 

But in this case, i think you both assume something that doesn't exist...

----------

## khayyam

krinn ...

at the time of my switching to mdev I did test if the udev useflag could be enabled, it failed. I forget the exact circumstances, and the error, and perhaps it was due to something else but in my case xorg failed to start. Anyhow, if you say it works then fine, but I'm not really seeing the need for switching between the two if {,s}mdev can function with 10-keyboard.conf, and in my case I didn't want/need udev installed. Is there a "real reason"? Well, I don't really see the use case where there would be a need to switch back and forth.

best ... khay

----------

## defer-

I removed unnecessary dependencies and added sys-fs/smdev to virtual/dev-manager.

 *khayyam wrote:*   

> Does smdev support /etc/mactab?

 

I think smdev does not support nameif/mactab but one could use something like this:

/etc/conf.d/net

```
preup() {

        [ "${IFACE}" = "lo" ] && return 0

        [ ! -d /dev/.udev -a -n "$( echo "${IFACE}" | grep -v "^br[0-9]\+$" )" ] && {

                einfo "Calling 'nameif' to set interface names"

                /sbin/nameif

        }

        return 0

} # preup
```

source: http://blog.stuart.shelton.me/archives/891

----------

## krinn

 *khayyam wrote:*   

> Is there a "real reason"? Well, I don't really see the use case where there would be a need to switch back and forth.

 

Just to allow to test smdev without need to remove udev and change too many things. It won't kill anyone if unnecessary blockers are removed anyway.

----------

## steveL

defer: I'd write that like this:

```
preup() {

   case $IFACE in

   br[0-9]*|*/br[0-9]*) [ -d /dev/.udev ]

   esac && return

   einfo "Calling 'nameif' to set interface names"

   /sbin/nameif

}
```

'case' exits true if nothing matches, same as 'if' does when no branch is taken (and no 'else'); otherwise they exit with the return status of whatever was last executed. There's no excuse to be calling out to grep. To be equivalent to the grep, you would lose the second option: and just test for: br[0-9]*) -- that may be preferable. I assumed we'd occasionally get /dev/br0 or whatever.

Could also use br[0-9]*|/dev/br[0-9]*) unless we always get the device name in that format?

By default I'd go for generality in the script, and leave it up to the admin to use what they like.

Sorry if this is bleary, just woke up..

edit to add: I agree with krinn about the blockers; unless something truly breaks when something else is installed, leave it up to the admin to install a working selection: that's their job.

----------

## defer-

I have been using smdev for two weeks without problems. I sent ebuild to Gentoo bugzilla.

https://bugs.gentoo.org/show_bug.cgi?id=520920

----------

## SlashBeast

Hi,

So the smdev is just an mdev with config placed into binary during compile time, not readed during runtime from /etc?

----------

## defer-

 *SlashBeast wrote:*   

> Hi,
> 
> So the smdev is just an mdev with config placed into binary during compile time, not readed during runtime from /etc?

 

It has similar functionality but different codebase. Might start deviating later.

----------

## SlashBeast

So I just checked the code and yes, its on pair with mdev in terms on functionality excluding the REGEX support for variables like DEVTYPE etc, which is like old-old mdev.c, but the config is bundled, meaning all config changes need recompilation.

I do like in general the fact that there's yet another dev manager like mdev or hotplug2. The code of smdev is small and clean, but I miss some comments that mdev do have, really help hacking it around, maybe if they add some features like the outstanding $ENV matching that mdev have I would switch to it.

----------

## NeddySeagoon

khayyam,

You can build Xorg with udev support then tell it not to use evdev in xorg.conf.

Going that path, you are compelled to use the old input drivers or Xorg will crash when it finds no input devices.

```
       Option "AutoAddDevices" "boolean"

              If  this  option is disabled, then no devices will be added from

              the HAL or udev backends. Enabled by default.
```

There is another option to allow Xorg to start with no input devices if you really want to.

----------

