Now that I have a Mounting tab I can see why we were not communicating fully in the previous thread. :-) I'm starting a new thread so we start on the same page.
With that dialog enabled, I now see you are using UUIDs in mediamanagerrc. I was unable to see that previously because without the underlying code being compiled that caused the missing Mounting tab, those features of TDEHW were not working. :-)
I don't know your TDEHW FIXME to-do list. So please accept my apology if I am covering topics you already know. :-)
* You already know about the problem of retaining the same icon label across different physical ports. Now that I have access to device-specific mounting options, I can see that mediamangerrc contains mounting options per UUID, but TDEHW remains confused about applying icon labels. From what I think I see after multiple insertions/removals of the same device across three different USB ports, TDEHW is assigning icon labels based upon device nodes rather than UUID. You mentioned in a previous post you saw the problem in the code, so I'll watch for a patch.
* Some features of the Mounting dialog are missing, which are reflected respectively in mediamanagerrc too. Here are some screenshots, the first set from a HAL system and the second set from TDEHW:
HAL:
http://humanreadable.nfshost.com/trinity/build_logs/mounting-dialog-floppy-h... http://humanreadable.nfshost.com/trinity/build_logs/mounting-dialog-usb-hal....
TDEHW:
http://humanreadable.nfshost.com/trinity/build_logs/mounting-dialog-floppy-t... http://humanreadable.nfshost.com/trinity/build_logs/mounting-dialog-usb-tdeh...
Missing features:
Generic Mount Options: Quiet Filesystem Specific Mount Options: Flushed IO Mount as user Short names
Here is a mediamanagerrc set of HAL configurations:
[/org/freedesktop/Hal/devices/volume_uuid_4840_B9DA] atime=false flush=true --> Missing mountpoint=/media/buffalo_1gb quiet=false --> Missing ro=false shortname=lower --> Missing sync=false uid=true --> Missing utf8=true
Here are the same UUID settings under TDEHW:
[4840-B9DA] atime=false automount=true mountpoint=/media/buffalo_1gb ro=false sync=false use_defaults=false utf8=true
* Safely Remove does not work. That is, using that option will unmount the device but does not remove the icon from the desktop.
* Eject does not work with CDs/DVDs.
* Icon appearance times remain weird, some fast, some very slow.
* Does TDEHW poll floppy drives? The floppy Mounting dialog (Unmounted Floppy icon) has a check box to mount automatically, but the option does not yet seem implemented.
Darrell
Now that I have a Mounting tab I can see why we were not communicating fully in the previous thread. :-) I'm starting a new thread so we start on the same page.
With that dialog enabled, I now see you are using UUIDs in mediamanagerrc. I was unable to see that previously because without the underlying code being compiled that caused the missing Mounting tab, those features of TDEHW were not working. :-)
I don't know your TDEHW FIXME to-do list. So please accept my apology if I am covering topics you already know. :-)
- You already know about the problem of retaining the same icon label
across different physical ports. Now that I have access to device-specific mounting options, I can see that mediamangerrc contains mounting options per UUID, but TDEHW remains confused about applying icon labels. From what I think I see after multiple insertions/removals of the same device across three different USB ports, TDEHW is assigning icon labels based upon device nodes rather than UUID. You mentioned in a previous post you saw the problem in the code, so I'll watch for a patch.
Patched in GIT hash b18416d.
- Some features of the Mounting dialog are missing, which are reflected
respectively in mediamanagerrc too. Here are some screenshots, the first set from a HAL system and the second set from TDEHW:
HAL:
http://humanreadable.nfshost.com/trinity/build_logs/mounting-dialog-floppy-h... http://humanreadable.nfshost.com/trinity/build_logs/mounting-dialog-usb-hal....
TDEHW:
http://humanreadable.nfshost.com/trinity/build_logs/mounting-dialog-floppy-t... http://humanreadable.nfshost.com/trinity/build_logs/mounting-dialog-usb-tdeh...
Missing features:
Generic Mount Options: Quiet Filesystem Specific Mount Options: Flushed IO Mount as user Short names
<snip>
Unfortunately those options are disabled on purpose due to limitations in pmount. Reading the man page (http://pwet.fr/man/linux/commandes/pmount) for pmount reveals no way to set those options; if someone bugs the upstream pmount project and they make those options available, those options can be reenabled in TDE with a few lines of code.
- Safely Remove does not work. That is, using that option will unmount the
device but does not remove the icon from the desktop.
Likely a udev/eject problem; it works here but your previous comments indicate that your udev subsystem may not be working as well for some reason.
- Eject does not work with CDs/DVDs.
See above comment.; not likely to be a TDE problem.
- Icon appearance times remain weird, some fast, some very slow.
Same as above.
- Does TDEHW poll floppy drives? The floppy Mounting dialog (Unmounted
Floppy icon) has a check box to mount automatically, but the option does not yet seem implemented.
Good question! I don't have a floppy drive handy to test with. Remember though that TDE relies on udev for transmission of all device plug/unplug/state-change events, so you might be able to find out using the udevadm monitor command I posted earlier.
Tim
Patched in GIT hash b18416d.
I'll test.
Missing features:
Generic Mount Options: Quiet Filesystem Specific Mount Options: Flushed IO Mount as user Short names
Unfortunately those options are disabled on purpose due to limitations in pmount. Reading the man page (http://pwet.fr/man/linux/commandes/pmount) for pmount reveals no way to set those options; if someone bugs the upstream pmount project and they make those options available, those options can be reenabled in TDE with a few lines of code.
What do users lose with those missing options?
How about having TDEHW migrate those settings to the new mediamanagerrc groups and gray/ghost the options in the dialog? That way users would see that the settings were migrated but not supported under TDEHW.
More TDEHW related information:
I see the following messages in my xsession log:
================================================= trying to create local folder /opt/trinity/share/config/tdehw: Permission denied
TQSocketNotifier: Invalid socket specified TQSocketNotifier: Internal error TQSocketNotifier: Invalid socket specified TQSocketNotifier: Internal error
[FIXME] UNCLASSIFIED DEVICE name: i2c-2 type: (null) subsystem: i2c-dev driver: (null) [Node Path: /dev/i2c-2] [Syspath: /sys/devices/pci0000:00/0000:00:03.0/0000:01:00.0/i2c-2/i2c-dev/i2c-2] [14f1:8852]
[FIXME] UNCLASSIFIED DEVICE name: i2c-3 type: (null) subsystem: i2c-dev driver: (null) [Node Path: /dev/i2c-3] [Syspath: /sys/devices/pci0000:00/0000:00:03.0/0000:01:00.0/i2c-3/i2c-dev/i2c-3] [14f1:8852]
[FIXME] UNCLASSIFIED DEVICE name: i2c-4 type: (null) subsystem: i2c-dev driver: (null) [Node Path: /dev/i2c-4] [Syspath: /sys/devices/pci0000:00/0000:00:03.0/0000:01:00.0/i2c-4/i2c-dev/i2c-4] [14f1:8852]
[FIXME] UNCLASSIFIED DEVICE name: i2c-5 type: (null) subsystem: i2c-dev driver: (null) [Node Path: /dev/i2c-5] [Syspath: /sys/devices/pci0000:00/0000:00:05.0/i2c-5/i2c-dev/i2c-5] [10de:0240]
[FIXME] UNCLASSIFIED DEVICE name: i2c-6 type: (null) subsystem: i2c-dev driver: (null) [Node Path: /dev/i2c-6] [Syspath: /sys/devices/pci0000:00/0000:00:05.0/i2c-6/i2c-dev/i2c-6] [10de:0240]
[FIXME] UNCLASSIFIED DEVICE name: i2c-0 type: (null) subsystem: i2c-dev driver: (null) [Node Path: /dev/i2c-0] [Syspath: /sys/devices/pci0000:00/0000:00:0a.1/i2c-0/i2c-dev/i2c-0] [10de:0264]
[FIXME] UNCLASSIFIED DEVICE name: i2c-1 type: (null) subsystem: i2c-dev driver: (null) [Node Path: /dev/i2c-1] [Syspath: /sys/devices/pci0000:00/0000:00:0a.1/i2c-1/i2c-dev/i2c-1] [10de:0264] =================================================
The first message is self-explanatory. Yet seems TDEHW should be trying to create the file in $TDEHOME/share/config and not $TDEDIR/share/config. Curious, I started TDE as root in the hopes of seeing what this directory might look like. The directory is created through the kcontrol module, but there were no files in the directory after being created.
I don't know what the TQSocketNotifier messages are about, if related to TDEHW. If not related they probably should be investigated and resolved anyway.
I suspect the FIXME messages are on the TDEHW to-do list?
Darrell
What do users lose with those missing options?
Nothing of any real importance IMHO.
How about having TDEHW migrate those settings to the new mediamanagerrc groups and gray/ghost the options in the dialog? That way users would see that the settings were migrated but not supported under TDEHW.
This is not easy due to the underlying architecture of the media manager system. Besides this, it would be confusing to most users to see greyed-out options for settings that the underlying code cannot support at this time.
More TDEHW related information:
I see the following messages in my xsession log:
================================================= trying to create local folder /opt/trinity/share/config/tdehw: Permission denied
Just ignore this. Eventually the idea is to allow users to configure udev through that module, but for now it only reads/displays the current system configuration.
TQSocketNotifier: Invalid socket specified TQSocketNotifier: Internal error
<snip>
I just pushed two new commits to tdelibs and tdebase; they should resolve the warnings printed above, as well as restore proper removable media device icons.
I suspect the FIXME messages are on the TDEHW to-do list?
Yes. If anyone ever sees these messages, please send them to this mailing list. They indicate that TDEHWLib did not recognize one or more devices on your system, and they also include enough information to fix detection.
Tim
Retaining the same icon label across different physical ports now works! :-)
How about having TDEHW migrate those settings to the new mediamanagerrc groups and gray/ghost the options in the dialog? That way users would see that the settings were migrated but not supported under TDEHW.
This is not easy due to the underlying architecture of the media manager system. Besides this, it would be confusing to most users to see greyed-out options for settings that the underlying code cannot support at this time.
Okay, don't show them in the GUI dialog. How about migrating the entire mediamanagerrc chunk for each device? Those four options would remain dormant under TDEHW, but would be there should TDEHW support them.
Observation (a different reason to copy the whole mediamanagerrc chunk for each device): TDEHW does not grep/inherit HAL settings in mediamanagerrc, requiring users to reconfigure each device that is different from the defaults. That is, each device under TDEHW defaults to the defaults. Users have to uncheck the "Use defaults" check box and reconfigure the device. Not to mention having to reconfigure the icon label. Paper cut nuisance, especially when we want TDEHW to be as seamless as possible --- the basic idea of "never breaking external interfaces." As both schemes use UUID I'm hoping this chunk copying should be straightforward. :-)
TQSocketNotifier: Invalid socket specified TQSocketNotifier: Internal error
I just pushed two new commits to tdelibs and tdebase; they should resolve the warnings printed above, as well as restore proper removable media device icons.
Aargh. :-) Rebuild again!
I suspect the FIXME messages are on the TDEHW to-do list?
Yes. If anyone ever sees these messages, please send them to this mailing list. They indicate that TDEHWLib did not recognize one or more devices on your system, and they also include enough information to fix detection.
Okay. You have that particular set of FIXME messages in your queue. :-)
More information:
CD/DVDs: Not sure how this works, but the following happens when I insert a disk under both HAL and TDEHW:
* An icon appears on the desktop. The icon label is the name of the disk label, such as "Slackware64-current DVD." * A dialog appears asking me what to do.
Then this happens under HAL:
* The disk mounts to a mount point the same as the disk label, such as "/media/Slackware64-current DVD" (Pretty!)
Under TDEHW:
* The disk mounts to the mount point of "/media/sr0" (Functional but not pretty)
Is there a way to get TDEHW to use a mount point like under HAL? I do not have anything in mediamanagerrc for optical disks. I don't know how TDE/HAL creates/uses a mount point that matches the disk label. I'm guessing something in the halbackend code that can be copied/pasted into the tdehwbackend code? :-)
* Compact flash disk icon: USB device rather than sd_mmc device: I'll test with the latest patches.
Darrell
CD/DVDs: Not sure how this works, but the following happens when I insert a disk under both HAL and TDEHW:
- An icon appears on the desktop. The icon label is the name
of the disk label, such as "Slackware64-current DVD."
- A dialog appears asking me what to do.
Then this happens under HAL:
- The disk mounts to a mount point the same as the disk
label, such as "/media/Slackware64-current DVD" (Pretty!)
Under TDEHW:
- The disk mounts to the mount point of "/media/sr0"
(Functional but not pretty)
Is there a way to get TDEHW to use a mount point like under HAL? I do not have anything in mediamanagerrc for optical disks. I don't know how TDE/HAL creates/uses a mount point that matches the disk label. I'm guessing something in the halbackend code that can be copied/pasted into the tdehwbackend code? :-)
I tested this under Xfce 4.10 and KDE 4.8.5. The mount point is the same as the disk label, just like TDE under HAL. For example "/media/Slackware64-current DVD." We probably want to be consistent and do the same?
- Compact flash disk icon: USB device rather than sd_mmc
device: I'll test with the latest patches.
This is fixed. :-)
Darrell
CD/DVDs: Not sure how this works, but the following happens when I insert a disk under both HAL and TDEHW:
- An icon appears on the desktop. The icon label is the name
of the disk label, such as "Slackware64-current DVD."
- A dialog appears asking me what to do.
Then this happens under HAL:
- The disk mounts to a mount point the same as the disk
label, such as "/media/Slackware64-current DVD" (Pretty!)
Under TDEHW:
- The disk mounts to the mount point of "/media/sr0"
(Functional but not pretty)
Is there a way to get TDEHW to use a mount point like under HAL? I do not have anything in mediamanagerrc for optical disks. I don't know how TDE/HAL creates/uses a mount point that matches the disk label. I'm guessing something in the halbackend code that can be copied/pasted into the tdehwbackend code? :-)
I tested this under Xfce 4.10 and KDE 4.8.5. The mount point is the same as the disk label, just like TDE under HAL. For example "/media/Slackware64-current DVD." We probably want to be consistent and do the same?
Is this regression specific to CDs/DVDs, or does the same problem exist with other media as well? I never paid too much attention to how HAL handled default mount points...
Thanks!
Tim
I tested this under Xfce 4.10 and KDE 4.8.5. The mount point is the same as the disk label, just like TDE under HAL. For example "/media/Slackware64-current DVD." We probably want to be consistent and do the same?
Is this regression specific to CDs/DVDs, or does the same problem exist with other media as well? I never paid too much attention to how HAL handled default mount points...
Hmm. I don't know ----
I renamed my mediamanagerrc file and inserted some USB flash drives.
With no mediamanagerrc file, the device appeared on the desktop as "1.0G Removable Media." When I let the dialog mount the device, the device point was /media/disk.
I left that device mounted and inserted another USB flash drive. Same similar icon name but the mount point was /media/disk-1.
I renamed the icon labels for both devices and Safely Removed. Then I inserted both devices again. The icon labels displayed correctly with my new names but the mount points were the same as previous, /media/disk and /media/disk-1.
Of course, I can use the popup menu dialog to explicitly define a mount point location for the USB devices.
In a HAL system I don't need to define a mount point for optical disks. The disk is always mounted to a mount point using the disk label, which matches the icon label. As mentioned in a previous post, that behavior is seen in Xfce 4.10 and KDE 4.8.5 too.
My guess is we need only copy/paste some code snippets from halbackend to tdehwbackend. I'll try to look but I'm not certain exactly what to search.
Darrell
Safely Remove does not work. That is, using that option will unmount the device but does not remove the icon from the desktop.
Likely a udev/eject problem; it works here but your previous comments indicate that your udev subsystem may not be working as well for some reason.
- Eject does not work with CDs/DVDs.
See above comment.; not likely to be a TDE problem.
I tested this under Xfce 4.10 and KDE 4.8.5 in Slackware 14. With both desktops eject works for optical disks and the icons disappear with the equivalent of Safely Remove. I don't think the problem is udev/eject problem. Also nobody is reporting eject problems with Slackware 14.
In my xsession log I see the following when I select Eject from the popup menu:
[tdeinit] Got EXT_EXEC 'eject' from launcher. [tdeinit] eject is executable and not a library. Launching with exec. ioctl: Input/output error
After selecting the Eject option from the popup menu, even root can't run the eject command from a terminal. Oddly, after I use the drive button to force the eject, the eject command starts working again for root and non root users. Seems as though there is a soft lock of some sort.
As you are not seeing either problem, at this point I suspect a build issue, similar to what we saw yesterday with the lone WITH_HAL qualifier.
Darrell
Safely Remove does not work. That is, using that option will unmount
the
device but does not remove the icon from the desktop.
Likely a udev/eject problem; it works here but your previous comments indicate that your udev subsystem may not be working as well for some reason.
- Eject does not work with CDs/DVDs.
See above comment.; not likely to be a TDE problem.
I tested this under Xfce 4.10 and KDE 4.8.5 in Slackware 14. With both desktops eject works for optical disks and the icons disappear with the equivalent of Safely Remove. I don't think the problem is udev/eject problem. Also nobody is reporting eject problems with Slackware 14.
Those two systems probably use a different method to request an eject operation. Does 'eject' work from the command line at all on your system?
Regarding the CD/DVD mountpoint, I am not entirely comfortable using the disk volume name as the mountpoint. I am especially concerned about what might happen if more than one disk uses the same name--normally this results in a nested mount on Linux, which is NOT what would be desired in this case.
Tim
Safely Remove does not work. That is, using that option will unmount
the
device but does not remove the icon from the desktop.
Likely a udev/eject problem; it works here but your previous comments indicate that your udev subsystem may not be working as well for some reason.
- Eject does not work with CDs/DVDs.
See above comment.; not likely to be a TDE problem.
I tested this under Xfce 4.10 and KDE 4.8.5 in Slackware 14. With both desktops eject works for optical disks and the icons disappear with the equivalent of Safely Remove. I don't think the problem is udev/eject problem. Also nobody is reporting eject problems with Slackware 14.
Those two systems probably use a different method to request an eject operation. Does 'eject' work from the command line at all on your system?
More information: TDE handles a HAL eject and a TDEHWLib eject the exact same way, via a call to kdeeject, which then calls eject. As eject used to rely on HAL, I would not be a bit surprised if the 'eject' binary is broken on Slackware 14 (the ioctl errors would support this hypothesis).
Tim
More information: TDE handles a HAL eject and a TDEHWLib eject the exact same way, via a call to kdeeject, which then calls eject. As eject used to rely on HAL, I would not be a bit surprised if the 'eject' binary is broken on Slackware 14 (the ioctl errors would support this hypothesis).
At this point I don't think eject is broken. As mentioned in a previous post, eject and icon disappearance is working on Slackware 14 with Xfce 4.10 and KDE 4.8.5. More, Slackware 14 is being heavily tested by many people and nobody is reporting breakage with eject.
As I mentioned, for the moment I'm suspecting a not-so-obvious build issue. I don't see any kdebug options to monitor kdeeject. I suppose I could temporarily enable all kdebug options and then watch stdout.
Darrell
More information: TDE handles a HAL eject and a TDEHWLib eject the exact same way, via a call to kdeeject, which then calls eject. As eject used to rely on HAL, I would not be a bit surprised if the 'eject' binary is broken on Slackware 14 (the ioctl errors would support this hypothesis).
At this point I don't think eject is broken. As mentioned in a previous post, eject and icon disappearance is working on Slackware 14 with Xfce 4.10 and KDE 4.8.5. More, Slackware 14 is being heavily tested by many people and nobody is reporting breakage with eject.
Can you try using kdeeject from the command line on your CD drive to see if it works at all?
Thanks!
Tim
Can you try using kdeeject from the command line on your CD drive to see if it works at all?
I tried, The result was an OK button dialog, "Eject failed!" I had everything in kdebugdialog enabled and I could not find anything related.
That "Eject failed!" dialog should provide some verbose information about the failure, or provide a "More details" button to provide why the command failed.
Darrell
Does 'eject' work from the command line at all on your system?
Yes and no.
The eject command works great to open and close the drive tray --- until I insert a disk. When I insert a disk and the drive tray closes, the eject command stops working. When I use the drive button to eject the disk, the eject command thereafter starts working again.
Hence my previous comment that there might be some kind of soft lock occuring.
I don't know why this does not happen on your system. Do you build with both WITH_HAL=ON and WITH_TDEHW=ON? If yes, possibly HAL is grabbing the Eject and Safely Remove commands rather than TDEHW?
I see that the Safely Remove option is a service type:
Exec=kio_media_mounthelper -s %u
and the Eject command is a service type too:
Exec=kio_media_mounthelper -e %u
Looks like kio_media_mounthelper is a good place to troubleshoot? Perhaps that command builds differently under WITH_HAL and WITH_TDEHW?
Regarding the CD/DVD mountpoint, I am not entirely comfortable using the disk volume name as the mountpoint. I am especially concerned about what might happen if more than one disk uses the same name--normally this results in a nested mount on Linux, which is NOT what would be desired in this case.
Yet this is the way TDE creates mount points on a HAL system and has been that way for years. :-)
How many people have two optical drives on their system and how many people insert two identical disks with the same volume label? That would be one heck of an unusual corner case. :-)
I have a spare box with both a CD reader and a DVD burner that has both KDE3 and TDE installed. I'll burn two identical CDs and see what happens.
I don't think breaking from the tradition or being different from the other desktops with this one feature will go over well with users. I hate WTF moments. :-)
Darrell
Does 'eject' work from the command line at all on your system?
Yes and no.
The eject command works great to open and close the drive tray --- until I insert a disk. When I insert a disk and the drive tray closes, the eject command stops working. When I use the drive button to eject the disk, the eject command thereafter starts working again.
Hence my previous comment that there might be some kind of soft lock occuring.
I don't know why this does not happen on your system. Do you build with both WITH_HAL=ON and WITH_TDEHW=ON? If yes, possibly HAL is grabbing the Eject and Safely Remove commands rather than TDEHW?
I see that the Safely Remove option is a service type:
Exec=kio_media_mounthelper -s %u
and the Eject command is a service type too:
Exec=kio_media_mounthelper -e %u
Looks like kio_media_mounthelper is a good place to troubleshoot? Perhaps that command builds differently under WITH_HAL and WITH_TDEHW?
I'm looking at tdebase/kioslave/media/mediamanager/CMakeLists.txt. I notice two differences:
Under WITH_HAL, linuxcdpolling.cpp is built but not otherwise. Second, under WITH_HAL, the LINK option includes ${DBUS_TQT_LIBRARIES} but otherwise not.
In other words, when building with WITH_HAL=OFF and WITH_TDEHW=ON, those two differences come into play.
I could try a simple patch to add those options and see what happens. Worse case is tdebase fails to build.
Darrell
I'm looking at tdebase/kioslave/media/mediamanager/CMakeLists.txt. I notice two differences:
Under WITH_HAL, linuxcdpolling.cpp is built but not otherwise. Second, under WITH_HAL, the LINK option includes ${DBUS_TQT_LIBRARIES} but otherwise not.
In other words, when building with WITH_HAL=OFF and WITH_TDEHW=ON, those two differences come into play.
I could try a simple patch to add those options and see what happens. Worse case is tdebase fails to build.
The patch did not help. Did not hinder either.
Built without failure too. Interesting.
Darrell
Does 'eject' work from the command line at all on your system?
Yes and no.
The eject command works great to open and close the drive tray --- until I insert a disk. When I insert a disk and the drive tray closes, the eject command stops working. When I use the drive button to eject the disk, the eject command thereafter starts working again.
Hence my previous comment that there might be some kind of soft lock occuring.
But TDE does not have any control over the operation of the system-provided eject command, nor does it have the ability to lock access to the CD drive. Can you use the eject command with a CD in the drive from within KDE4 or XFCE?
I have a spare box with both a CD reader and a DVD burner that has both KDE3 and TDE installed. I'll burn two identical CDs and see what happens.
I don't think breaking from the tradition or being different from the other desktops with this one feature will go over well with users. I hate WTF moments. :-)
Of course, and I do understand the rationale. However, this corner case is still a real possibility, and we don't want an even bigger WTF moment if it is triggered for some reason.
A reasonable compromise might be to include the dev node name at the end of the mount point in brackets, i.e. "/media/My CD Label (sr0)". Once we know how HAL handles this corner case via your test I can try to duplicate its behaviour as much as possible.
Tim
If ( Name exists) { Name = Name + id } Mount On Sep 2, 2012 7:32 PM, "Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:
Does 'eject' work from the command line at all on your system?
Yes and no.
The eject command works great to open and close the drive tray --- until
I
insert a disk. When I insert a disk and the drive tray closes, the eject command stops working. When I use the drive button to eject the disk, the eject command thereafter starts working again.
Hence my previous comment that there might be some kind of soft lock occuring.
But TDE does not have any control over the operation of the system-provided eject command, nor does it have the ability to lock access to the CD drive. Can you use the eject command with a CD in the drive from within KDE4 or XFCE?
I have a spare box with both a CD reader and a DVD burner that has both KDE3 and TDE installed. I'll burn two identical CDs and see what happens.
I don't think breaking from the tradition or being different from the other desktops with this one feature will go over well with users. I hate WTF moments. :-)
Of course, and I do understand the rationale. However, this corner case is still a real possibility, and we don't want an even bigger WTF moment if it is triggered for some reason.
A reasonable compromise might be to include the dev node name at the end of the mount point in brackets, i.e. "/media/My CD Label (sr0)". Once we know how HAL handles this corner case via your test I can try to duplicate its behaviour as much as possible.
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Does 'eject' work from the command line at all on your system?
Yes and no.
The eject command works great to open and close the drive tray --- until I insert a disk. When I insert a disk and the drive tray closes, the eject command stops working. When I use the drive button to eject the disk, the eject command thereafter starts working again.
Hence my previous comment that there might be some kind of soft lock occuring.
But TDE does not have any control over the operation of the system-provided eject command, nor does it have the ability to lock access to the CD drive. Can you use the eject command with a CD in the drive from within KDE4 or XFCE?
This is very likely a kernel problem: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/986845
Tim
This is very likely a kernel problem: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/986845
Slackware 14 is using 3.2.28.
As nobody is reporting eject problems, I don't expect much help from the Slackware community because Trinity is not an officially supported desktop. Xfce 4.10 and KDE 4.8.5 are officially supported and eject works fine with both.
Darrell
This is very likely a kernel problem: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/986845
Slackware 14 is using 3.2.28.
As nobody is reporting eject problems, I don't expect much help from the Slackware community because Trinity is not an officially supported desktop. Xfce 4.10 and KDE 4.8.5 are officially supported and eject works fine with both.
Darrell
I understand what you are saying, however AFAIK KDE4 and Xfce do not use the eject command (they probably use udisks or similar), therefore I would not expect any problems with 'eject' to be reported even if they did exist.
I can't fix (or sometimes even work around) core Linux system problems by modifying TDE... :-)
Tim
I understand what you are saying, however AFAIK KDE4 and Xfce do not use the eject command (they probably use udisks or similar), therefore I would not expect any problems with 'eject' to be reported even if they did exist.
I can't fix (or sometimes even work around) core Linux system problems by modifying TDE... :-)
I'll try to learn more. When I performed the tests in Xfce 4.10 and KDE 4.8.5, I did not test from the command line. Only through the desktop GUI. If what you say is true, then a command line test might not prove anything if those desktops do not use the eject command in any way.
I posted a query to the Slackware forum but I'm not optimistic because Trinity is not offically supported.
I have some older udev packages I can test. I also could configure udisks not to run or remove the package altogether to see whether there is a conflict somewhere. I'm leaning toward something soft locking the devices that prevents kio_media_mounthelper from working, for both for the Eject action and the Safely Remove action. My gut says whatever is causing the lock is affecting both since both actions are performed through the kio_media_mounthelper command. I use the phrase soft lock because the drive eject button still works. Only the TDE actions fail and only under TDEHW. Once the eject button is pressed, the eject command works thereafter.
Darrell
I understand what you are saying, however AFAIK KDE4 and Xfce do not use the eject command (they probably use udisks or similar), therefore I would not expect any problems with 'eject' to be reported even if they did exist.
I can't fix (or sometimes even work around) core Linux system problems by modifying TDE... :-)
I'll try to learn more. When I performed the tests in Xfce 4.10 and KDE 4.8.5, I did not test from the command line. Only through the desktop GUI. If what you say is true, then a command line test might not prove anything if those desktops do not use the eject command in any way.
It would prove something if the eject command fails under those desktops. If it fails, it would prove that the eject command is broken in an officially supported desktop, and therefore should be fixed. If it does not fail, it would indicate that TDE is doing something slightly different that either exposes an existing bug in the eject system or directly causes it to fail.
Tim
<snip>
A reasonable compromise might be to include the dev node name at the end of the mount point in brackets, i.e. "/media/My CD Label (sr0)". Once we know how HAL handles this corner case via your test I can try to duplicate its behaviour as much as possible.
Tim
I went ahead and committed logic for this solution into GIT in tdelibs and tdebase. This preserves pretty mount paths without adding a large chunk of new path usage counting logic to the media manager.
Tim
A reasonable compromise might be to include the dev node name at the end of the mount point in brackets, i.e. "/media/My CD Label (sr0)". Once we know how HAL handles this corner case via your test I can try to duplicate its behaviour as much as possible.
I tested this on a 3.5.10 system with the DVD and CD drives. Both disks had the same volume label. There were no problems. The mount point names were handled in the same manner as reported earlier with using default mount names of disk, disk-1, etc. with USB flash drives. In this case, I ended up with the first disk being mounted at "/media/Slackware Install1" and the second disk being mounted at "/media/Slackware Install1-1."
Using volume labels does not result in a mount point naming conflict or mindless loop.
I repeated the test on the same machine using an older GIT version of TDE. Of course, like the 3.5.10 system, that set of packages were built with HAL rather than TDEHW support. The mount results were the same.
I see you committed some patches, but I will need a couple of days to test TDEHW on the dual optical disk machine because I have to build 32-bit packages to test. All of my previous TDEHW testing has been with 64-bit packages.
Darrell
A reasonable compromise might be to include the dev node name at the end of the mount point in brackets, i.e. "/media/My CD Label (sr0)". Once we know how HAL handles this corner case via your test I can try to duplicate its behaviour as much as possible.
I tested this on a 3.5.10 system with the DVD and CD drives. Both disks had the same volume label. There were no problems. The mount point names were handled in the same manner as reported earlier with using default mount names of disk, disk-1, etc. with USB flash drives. In this case, I ended up with the first disk being mounted at "/media/Slackware Install1" and the second disk being mounted at "/media/Slackware Install1-1."
Using volume labels does not result in a mount point naming conflict or mindless loop.
I repeated the test on the same machine using an older GIT version of TDE. Of course, like the 3.5.10 system, that set of packages were built with HAL rather than TDEHW support. The mount results were the same.
I see you committed some patches, but I will need a couple of days to test TDEHW on the dual optical disk machine because I have to build 32-bit packages to test. All of my previous TDEHW testing has been with 64-bit packages.
Darrell
OK, thank you for the information. If you want to, you can comment out line 999 of file tdehardwarebackend.cpp and see if the TDEHWLib backend handles the same situation(two identical volume labels) gracefully or not. If it does, that line of code can be removed from GIT.
Tim
A reasonable compromise might be to include the dev node name at the end of the mount point in brackets, i.e. "/media/My CD Label (sr0)". Once we know how HAL handles this corner case via your test I can try to duplicate its behaviour as much as possible.
I tested this on a 3.5.10 system with the DVD and CD drives. Both disks had the same volume label. There were no problems. The mount point names were handled in the same manner as reported earlier with using default mount names of disk, disk-1, etc. with USB flash drives. In this case, I ended up with the first disk being mounted at "/media/Slackware Install1" and the second disk being mounted at "/media/Slackware Install1-1."
Using volume labels does not result in a mount point naming conflict or mindless loop.
I repeated the test on the same machine using an older GIT version of TDE. Of course, like the 3.5.10 system, that set of packages were built with HAL rather than TDEHW support. The mount results were the same.
I see you committed some patches, but I will need a couple of days to test TDEHW on the dual optical disk machine because I have to build 32-bit packages to test. All of my previous TDEHW testing has been with 64-bit packages.
Darrell
OK, thank you for the information. If you want to, you can comment out line 999 of file tdehardwarebackend.cpp and see if the TDEHWLib backend handles the same situation(two identical volume labels) gracefully or not. If it does, that line of code can be removed from GIT.
Tim
Sorry, I posted the wrong action above. Instead of commenting out line 999, you would need to replace it with this line of code: diskLabel = medium->label();
Tim
Sorry, I posted the wrong action above. Instead of commenting out line 999, you would need to replace it with this line of code:
diskLabel = medium->label();
I haven't yet tried a build with the modified line.
The code as-is works great. Using two disk of the same volume label, mounted automatically as follows:
Slackware Install1 (sr0) Slackware Install1 (sr1)
No conflicts.
Darrell
OK, thank you for the information. If you want to, you can comment out line 999 of file tdehardwarebackend.cpp and see if the TDEHWLib backend handles the same situation(two identical volume labels) gracefully or not. If it does, that line of code can be removed from GIT.
I rebuilt tdelibs/tdebase 64-bit. I see what you did with the optical disk mount point naming. Looks great to me, best of both worlds and satisfies all concerns. Fundamentally, the previous scheme of appending a number is no different, but the new scheme actually is nicer and saner. :-)
I plan to run a 32-bit package build set overnight but the final testing will be late tomorrow at the earliest. The machine with two optical drives is a PII with an IDE hard drive. V---e---r---y---s---l---o---w to install a full updated package set. :-)
I'll run the first test with line 999 as is. I should see something like this:
Slackware Install1 (hdb) Slackware Install1 (hdc)
Or something similar.
Unless the old numerical appendage is in the tdehwbackend code, I'm curious to see what happens with a package rebuilt with line 999 commented out. We'll see how that goes tomorrow. :-)
Darrell
-
Calvin Morrison -
Darrell Anderson -
Timothy Pearson