| Message ID | 7964be0c75358121baa69301d23eb93d72a64db9.1405777634.git.yann.morin.1998@free.fr |
|---|---|
| State | Superseded |
| Headers | show |
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote in news:7964be0c75358121baa69301d23eb93d72a64db9.1405777634.git.yann.morin.199 8@free.fr: > xserver_xorg-server is happy enough with just a libudev, and does > not require a udev daemon. Hi, although it is true that xserver_xorg-server compiles with libudev alone it segfaults at runtime when checking for video hardware without udev daemon: ======================================================================== (gdb) run Starting program: /usr/bin/Xorg :0.0 vt01 -s 0 -noreset -allowMouseOpenFail -logfile /data/log/xorg.log [...] X.Org X Server 1.16.0 [...] Program received signal SIGSEGV, Segmentation fault. 0x080e058a in xf86OutputClassDriverList (nmatches=20, matches=0xbffff710, index=0) at xf86platformBus.c:260 260 xf86platformBus.c: No such file or directory. (gdb) bt full #0 0x080e058a in xf86OutputClassDriverList (nmatches=20, matches= 0xbffff710, index=0) at xf86platformBus.c:260 cl = <optimized out> i = 0 #1 xf86PlatformMatchDriver (matches=matches@entry=0xbffff710, nmatches=nmatches@entry=20) at xf86platformBus.c:297 i = 0 j = 0 info = <optimized out> pass = 0 #2 0x080e3975 in listPossibleVideoDrivers (matches=matches@entry= 0xbffff710, nmatches=20) at xf86AutoConfig.c:203 i = 0 #3 0x080e3b22 in xf86AutoConfig () at xf86AutoConfig.c:152 deviceList = {0x0 <repeats 20 times>} p = <optimized out> cp = <optimized out> buf = "\b\000\000\000\b\000\000\000\b\000\000\000\b\000\000\000\200 \370\377\277", '\000' <repeats 60 times>, "\206\200\022\004\a\004\220\000 \006\000\000\003\000\000\000\000\004\000\000\360\000\000\000\000\f\000\000 \340\000\000\000\000\001\360\000\000\000\000\000\000\000\000\000\000I\030 \022\004\000\000\000\000\220\000\000\000\000\000\000\000\v\001\000\000\t \000\f\001m\200\204b\320\000DV\000\000\000\000A\002\000\000\071\000\000\000 \000\000\000\000\001\000\240\317\000\000\002", '\000' <repeats 45 times>... ret = <optimized out> #4 0x080c075a in InitOutput (pScreenInfo=pScreenInfo@entry=0x822b260 <screenInfo>, argc=argc@entry=9, argv=argv@entry=0xbffffd44) at xf86Init.c:476 i = <optimized out> j = <optimized out> k = <optimized out> scr_index = <optimized out> modulelist = <optimized out> optionlist = 0x822b260 <screenInfo> screenpix24 = <optimized out> pix24 = <optimized out> pix24From = X_DEFAULT pix24Fail = 0 autoconfig = 1 sigio_blocked = 0 want_hw_access = 0 configured_device = <optimized out> #5 0x0807e7e4 in dix_main (argc=argc@entry=9, argv=argv@entry=0xbffffd44, envp=envp@entry=0xbffffd6c) at main.c:202 i = <optimized out> alwaysCheckForInput = {0, 1} #6 0x080686fe in main (argc=9, argv=0xbffffd44, envp=0xbffffd6c) at stubmain.c:34 No locals. (gdb) ======================================================================== strace shows: open("/etc/udev/udev.conf", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) access("/run/udev/control", F_OK) = -1 ENOENT (No such file or directory) Luckily enough xserver_xorg-server does not depend on udev/hal, configure just prints: configure: WARNING: *********************************************** Neither HAL nor udev backend will be enabled. Input device hotplugging will not be available! *********************************************** which is fine for me, everything works good without udev/hal ;) Regards, Bernd
Bernd Kuhls <bernd.kuhls@t-online.de> wrote in news:XnsA3777C2F4BB23berndkuhlsPkbjNfxxIA@bernd-kuhls.de: > Luckily enough xserver_xorg-server does not depend on udev/hal, configure > just prints: > > configure: WARNING: > *********************************************** > Neither HAL nor udev backend will be enabled. > Input device hotplugging will not be available! > *********************************************** > > which is fine for me, everything works good without udev/hal ;) Hi, a small, but important addition: To avoid xserver_xorg-server picking up libudev when the udev daemon is disabled this patch is needed for xserver_xorg-server.mk: @@ -134,6 +134,7 @@ XSERVER_XORG_SERVER_CONF_OPT += --disable-config-udev-kms endif else +XSERVER_XORG_SERVER_CONF_OPT += --disable-config-udev ifeq ($(BR2_PACKAGE_DBUS),y) XSERVER_XORG_SERVER_DEPENDENCIES += dbus XSERVER_XORG_SERVER_CONF_OPT += --enable-config-dbus Regards, Bernd
Dear Bernd Kuhls, On Sun, 27 Jul 2014 12:12:29 +0200, Bernd Kuhls wrote: > "Yann E. MORIN" <yann.morin.1998@free.fr> wrote in > news:7964be0c75358121baa69301d23eb93d72a64db9.1405777634.git.yann.morin.199 > 8@free.fr: > > > xserver_xorg-server is happy enough with just a libudev, and does > > not require a udev daemon. > > although it is true that xserver_xorg-server compiles with libudev alone it > segfaults at runtime when checking for video hardware without udev daemon: That's the kind of thing that worries me about the idea of allowing only libudev to be installed without the udev daemon running. I believe libudev and the udev daemon are meant to be used together, and we're likely to fall into various issues by allowing libudev to be installed separately from the udev daemon. Best regards, Thomas
Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8 @public.gmane.org> wrote in news:20140727143111.7f5091a0@free-electrons.com: > That's the kind of thing that worries me about the idea of allowing > only libudev to be installed without the udev daemon running. I believe > libudev and the udev daemon are meant to be used together, and we're > likely to fall into various issues by allowing libudev to be installed > separately from the udev daemon. Hi Thomas, and thats exactly the reason why I suggest to switch only those packages over to libudev which are proven to work without the udev daemon. This is true for mesa3d/libcec/xbmc/libdrm/xdriver_xf86-video-intel, the packages I am using on my non-udev-daemon system. Regards, Bernd
Bernd, All, On 2014-07-27 13:38 +0200, Bernd Kuhls spake thusly: > Bernd Kuhls <bernd.kuhls@t-online.de> wrote in > news:XnsA3777C2F4BB23berndkuhlsPkbjNfxxIA@bernd-kuhls.de: > > > Luckily enough xserver_xorg-server does not depend on udev/hal, configure > > just prints: > > > > configure: WARNING: > > *********************************************** > > Neither HAL nor udev backend will be enabled. > > Input device hotplugging will not be available! > > *********************************************** > > > > which is fine for me, everything works good without udev/hal ;) > > Hi, > > a small, but important addition: To avoid xserver_xorg-server picking up > libudev when the udev daemon is disabled this patch is needed for > xserver_xorg-server.mk: > > @@ -134,6 +134,7 @@ > XSERVER_XORG_SERVER_CONF_OPT += --disable-config-udev-kms > endif > else > +XSERVER_XORG_SERVER_CONF_OPT += --disable-config-udev > ifeq ($(BR2_PACKAGE_DBUS),y) > XSERVER_XORG_SERVER_DEPENDENCIES += dbus > XSERVER_XORG_SERVER_CONF_OPT += --enable-config-dbus So, we can make this package work in the three cases: - _HAS_UDEV (implies _HAS_LIBUDEV) - _HAS_LIBUDEV && !_HAS_UDEV - !_HAS_LIBUDEV Correct? Regards, Yann E. MORIN.
Thomas, All, On 2014-07-27 14:31 +0200, Thomas Petazzoni spake thusly: > On Sun, 27 Jul 2014 12:12:29 +0200, Bernd Kuhls wrote: > > "Yann E. MORIN" <yann.morin.1998@free.fr> wrote in > > news:7964be0c75358121baa69301d23eb93d72a64db9.1405777634.git.yann.morin.199 > > 8@free.fr: > > > > > xserver_xorg-server is happy enough with just a libudev, and does > > > not require a udev daemon. > > > > > although it is true that xserver_xorg-server compiles with libudev alone it > > segfaults at runtime when checking for video hardware without udev daemon: > > That's the kind of thing that worries me about the idea of allowing > only libudev to be installed without the udev daemon running. I believe > libudev and the udev daemon are meant to be used together, and we're > likely to fall into various issues by allowing libudev to be installed > separately from the udev daemon. Well, I was a bit overzealous when converting the xserver_xorg-server package, on purpose. I wanted to stirr some questionning about it. Ditto for other packages in the series. The reasonning was: if we do not switch them over to using libudev and we would never switch those packages. On the other hand, if we switch all packages to use libudev (except those we know require udev), then users will report breakage, and we can revert back. So, I should not switch this package to use libudev, now we have a report it is broken. I'll remove it from the series. But, as Bernd stated, there *are* packages that work very well with kust libudev and no udev daemon. And in some cases, an udev daemon may not be wanted (for different reasons.) So we must be able to just provide libudev if at all possible. Regards, Yann E. MORIN.
Bernd, All, On 2014-07-27 14:38 +0200, Bernd Kuhls spake thusly: > Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8 > @public.gmane.org> wrote in news:20140727143111.7f5091a0@free-electrons.com: > > > That's the kind of thing that worries me about the idea of allowing > > only libudev to be installed without the udev daemon running. I believe > > libudev and the udev daemon are meant to be used together, and we're > > likely to fall into various issues by allowing libudev to be installed > > separately from the udev daemon. > > and thats exactly the reason why I suggest to switch only those packages over > to libudev which are proven to work without the udev daemon. This is true for > mesa3d/libcec/xbmc/libdrm/xdriver_xf86-video-intel, the packages I am using > on my non-udev-daemon system. I can see the reasonning. But if we do not convert those packages, they will never be. If we do convert them. we can be sure to get complains by angry users! Adn we can then revert broken packages. What I would suggest is the following plan: - for the next release (-rc1 due shortly), only convert packages known to work with only libudev, that is the list provided by Bernd: mesa3d libcec xbmc libdrm xdriver_xf86-video-intel so we have a sane situation for the release, and not too much burden during the stabilisation phase. - when -rc1 is out, or early after -next is merged back in master, convert the remaining packages in -next, after _testing_ the packages are still working. Unfortunately, I won't be able to test all such packages (e.g. xserver_xorg-server) as I do not use Xorg; but Bernd uses it, so he may be able to give a hand at it, correct? How do you feel with this plan? Regards, Yann E. MORIN.
diff --git a/package/x11r7/xserver_xorg-server/xserver_xorg-server.mk b/package/x11r7/xserver_xorg-server/xserver_xorg-server.mk index 779c46d..a83feec 100644 --- a/package/x11r7/xserver_xorg-server/xserver_xorg-server.mk +++ b/package/x11r7/xserver_xorg-server/xserver_xorg-server.mk @@ -123,8 +123,8 @@ XSERVER_XORG_SERVER_DEPENDENCIES += tslib XSERVER_XORG_SERVER_CONF_OPT += --enable-tslib LDFLAGS="-lts" endif -ifeq ($(BR2_PACKAGE_HAS_UDEV),y) -XSERVER_XORG_SERVER_DEPENDENCIES += udev +ifeq ($(BR2_PACKAGE_HAS_LIBUDEV),y) +XSERVER_XORG_SERVER_DEPENDENCIES += libudev XSERVER_XORG_SERVER_CONF_OPT += --enable-config-udev # udev kms support depends on libdrm ifeq ($(BR2_PACKAGE_LIBDRM),y)
xserver_xorg-server is happy enough with just a libudev, and does not require a udev daemon. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> --- package/x11r7/xserver_xorg-server/xserver_xorg-server.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)