Version: unspecified (using KDE 4.6.0) OS: Linux i can't provide many informations by now. It seems like solid doesn't recognize the stick anymore, as kaffeine tells me the device isn't connected, but it actually is. The stick is working using me-tv or any other application which doesn't use solid. It worked using KDE SC 4.5.5 and stopped after upgrading to 4.6 last night. Reproducible: Always Steps to Reproduce: Use Sundtek MediaTV Pro Stick and KDE SC 4.6 Installation following http://support.sundtek.com/index.php?topic=2.0 Actual Results: Kaffeine tells me no proper device is detected and in the settings the device is listed, as it worked until KDE 4.6, but listed as not connected Expected Results: kaffeine should play the selected TV programm janmalte@ubuntu:~$ kaffeine --nofork QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: Datei oder Verzeichnis nicht gefunden QFileSystemWatcher: failed to add paths: /home/janmalte/.config/ibus/bus Bus::open: Can not get ibus-daemon's address. IBusInputContext::createInputContext: no connection to ibus-daemon anmalte@ubuntu:~$ cat .kde/share/config/kaffeinerc [DVB] BeginMargin=300 ChannelViewState=AAAA/wAAAAAAAAABAAAAAAAAAAEBAAAAAAAAAAAAAAAAAAAAAAAAARUAAAACAQEAAQAAAAAAAAAAAAAAAGT/////AAAAgQAAAAAAAAACAAAApQAAAAEAAAAAAAAAcAAAAAEAAAAA EndMargin=600 LastChannel=ProSieben Latitude=0 Longitude=0 Override6937=false RecordingFolder=/home/janmalte/Videos/TV Aufnahmen TabSplitterState=AAAA/wAAAAAAAAACAAABMgAAA8sBAAAAAwEAAAAB TimeShiftFolder=/home/janmalte janmalte@ubuntu:~$ cat .kde/share/apps/kaffeine/config.dvb [device] deviceId= frontendName=Sundtek DVB-C configCount=1 [config] type=0 name=Kabel scanSource=de-Kabel_BW timeout=1500 janmalte@ubuntu:~$ dmesg | grep DVB janmalte@ubuntu:~$ ls /dev/dvb/adapter0 demux0 dvr0 frontend0 janmalte@ubuntu:~$ dmesg | grep Sun [ 23.883456] input: Sundtek Ltd. Remote Control as /devices/virtual/input/input4 [ 6442.838557] input: Sundtek Ltd. Remote Control as /devices/virtual/input/input5 [32514.348396] input: Sundtek Ltd. Remote Control as /devices/virtual/input/input6
Try by executing kaffeine this way: "SOLID_HAL_LEGACY=1 kaffeine" Thanks.
Thanks. Kaffeine is working this way. Will this be fixed in any way or do i have to create a new menu entry for kaffeine with this command?
That means that it works with the old HAL backend, so the problem is within the UDEV backend. I'm going to take a look at how you can provide more information so we can fix the bug in a proper way.
Just to be sure, can you check what udev packages do you have installed? and maybe some information about your distro? Thanks.
janmalte@ubuntu:~$ dpkg --get-selections | grep udev libgudev-1.0-0 install libudev0 install system-config-printer-udev install udev install janmalte@ubuntu:~$ uname -a Linux ubuntu 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:44 UTC 2011 x86_64 GNU/Linux My system is a Kubuntu 10.10 using KDE SC 4.6 from Backports PPA upgraded from 4.5.5 at 26.01.2011 in the evening. Do you need any other information?
Can you please paste the results of: $ solid-hardware list details $ SOLID_HAL_LEGACY=1 solid-hardware list details ?
Created attachment 56744 [details] output of $solid-hardware list details
Created attachment 56745 [details] output of $SOLID_HAL_LEGACY=1 solid-hardware list details
The problem is that there are no udev entries available for those devices, all they have are entries in /dev/dvb Since HAL offered a unix domain socket for device registration we used that one to add some preferences of our devices however udev does not offer such a feature yet. If one of you guys needs a sample device for testing the behavior of this we can ship one.
This still happens in KDE-4.7.0 Hal is deprecated and not used by any distribution or desktop anymore so installing it is no option for me. Is there any resolution in sight?
Seems that sundtek is shipping now udev rules for their cards, can you test them and see if this bug is now fixed? Thanks.
The problem is a general issue of KDE. There are several other ways to include DVB devices in Linux. 1. Userspace drivers 2. Network drivers 3. Kernel Systemdrivers (old way which exist first) The old way uses udev and entries in /sys to expose a device to a system, alternative drivers or interfaces won't be able to do that. We provide some patch for kaffeine to check /dev/dvb for changes Patches for Kaffeine can be found: http://support.sundtek.com/index.php/topic,546.msg4162.html#msg4162 The udev rules only create USB raw device nodes in the system.
By the way, there is a network box upcoming, which can use the device via Network, so we cover case 1 and case 2 but are not able to satisfy case 3. The network feature already exists in software and can be used with 2 Linux PCs or a Linux Router.
What is the status of this? is it any better with current kernel and driver? is there anything we should do? Thanks !
The problem is that is that the solid DVB hardware detection is bound to real devices only which use udev and sysfs. However it is possible to write drivers on application level which neither use udev nor sysfs, so solid won't pick them up. Eg. our virtual network devices won't be recognized by solid. The only workaround which is currently available is to patch the application, however the main issue is within the KDE hardware detection that it's not flexible enough.
Well, how can we list those devices? is there any way? we could cook a backend for libsolid to list them but we need to know how to do it.
As mentioned we have some workaround for that for Kaffeine http://sundtek.de/support/sundtek_0.3.diff This is checking inodes in /dev/dvb rather than sysfs entries If something like that would be included the network streaming server would also be supported out of the box again.
Can't this devices be listed with udev? UDev is the standard way of doing such things in linux, adding a specific backend for a specific hardware seems like a workaround :/
Unfortunately no. Please note this is all a little bit special, we can even use the devices via network. http://support.sundtek.com/index.php/topic,179.0.html In the early days it worked because the driver sent HAL messages on device attach/detach, now since HAL is gone on Linux that way doesn't work anymore. We'd dig into KDE however we're busy with our upcoming devices at the moment...
Maybe we should just close this issue? Seems like this issue is not getting fixed with KDE so we just drop support for KDE based DVB applications. KDE cannot recognize our application based DVB drivers (or application based DVB network drivers) which do not emit udev signals or expose information in /sys. Old KDE libraries supported a virtual registration via HAL, the current KDE library broke this behavior.
Alex, does comment #19 provide the requested information? Please set the bug status.
No response, changing status. Please close if this cannot be supported.
We modified kaffeine, the modification is upstream so it won't be a problem anymore. Solid is not flexible enough for hardware detection it should not be used for hardware detection. Linux, Windows, Mac, Solaris all of them allow userspace drivers nowadays, only restricting this to kernel drivers is technology of the past but definitely not the current state of art.
For the record, for people who will land here in future without previous knowledge of the issue, the problem was discussed in the past (on IRC) and solution were proposed. Solid *is* flexible enough if you write a backend for your devices only. The patch which landed in Kaffeine (whose code quality can be questionable) is not the "proper" mantaineable solution.
It shouldn't have broke in first instance (for years already) when solid went mainstream, writing a backend requires another full KDE update which will take much more time. the less dependencies the better it is for hardware detection.
(In reply to Markus Rechberger from comment #25) > It shouldn't have broke in first instance (for years already) when solid > went mainstream, writing a backend requires another full KDE update which > will take much more time. the less dependencies the better it is for > hardware detection. Nothing was broken, a new unknown (from udev point of view) device was introduced. Moreover, this bug was filed in 2011, we had enough releases to include a new backend. There is still time to add one for Frameworks.
This bug is reported on libsolid which is the kdelibs4 version of the solid library. It is now in maintenance mode. If you think it should still be fixed in the KDE Frameworks 5 version of solid please move it to or report a bug on frameworks-solid.
Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I am closing this bug. Please try again with the latest version and submit a new bug to frameworks-solid if your issue persists. Thank you!