AFAIK the opening/closing the tray doesn't generate udev events.akash_rawal wrote:Do you manage to get udev or kernel events for opening and closing tray? If no, that could be the problem.jemimah wrote: Pup-volume-monitor-shows the correct information - the only problem is that updates to the optical drive never make it to Thunar or xfdesktop.
I can script around the audio CD problem - but getting DVDs and data disks to show up on the desktop should be an easy fix (they do show up as USB drives). I just haven't figured out what the fix is.
Currently hotplugging of USB drives works fine.
I am not interested in relying on udev events for optical drives. In next version the volume monitor will do its own probing of optical drives.
Rewriting pup_event in C
[url]http://saluki-linux.com[/url]
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
The next version 0.1.0 has arrived.
I have added plugin and config support (There will be one at /etc/xdg/pup-volume-monitor/main.conf), and support for interactive mount operations and optical drive support as a plugin.
I have tried using libburn to do this. It was able to show the type of disk (like CD-R, CD-RW, ...) but ended up locking the optical drive tray several times. It was quite slow too.
I am now using blkid and ioctl calls to probe for optical drives. It's fast but it can't detect type of disk.
And I discover, ioctl calls on drive generates kernel events for opening and closing tray. However I am not using it.
Currently it can detect only upto audio cds, and that too I haven't tested yet. I don't have any. If ioctl reports that inserted disk is an audio cd, it should use media-cdrom-audio icon and any attempt to mount it should give an error.
I have added plugin and config support (There will be one at /etc/xdg/pup-volume-monitor/main.conf), and support for interactive mount operations and optical drive support as a plugin.
I have tried using libburn to do this. It was able to show the type of disk (like CD-R, CD-RW, ...) but ended up locking the optical drive tray several times. It was quite slow too.
I am now using blkid and ioctl calls to probe for optical drives. It's fast but it can't detect type of disk.
And I discover, ioctl calls on drive generates kernel events for opening and closing tray. However I am not using it.
Code: Select all
# udevadm monitor --kernel
monitor will print the received events for:
KERNEL - the kernel uevent
KERNEL[1339013226.789550] change /devices/pci0000:00/0000:00:1f.2/host3/target3:0:0/3:0:0:0/block/sr0 (block)
KERNEL[1339013230.808583] change /devices/pci0000:00/0000:00:1f.2/host3/target3:0:0/3:0:0:0/block/sr0 (block)
You can make one. Get a few mp3 and use pburn to make an audio cd of themakash_rawal wrote:Currently it can detect only upto audio cds, and that too I haven't tested yet. I don't have any.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
Is this because blkid executable uses high-level probing, while I use low-level probe?jemimah wrote:It's not a PATH issue. Blkid correctly returns info about every drive except the one in question. It's bizarre.akash_rawal wrote:udev removes the entire environment , including PATH variable. You have to re-export it yourself or use full path to blkid.jemimah wrote: but for some reason the blkid command returns incomplete output when run from a script called by udev as opposed to the command line. I can't figure out why.
High-level probing reads /proc/partitions to get list of the drives, which might be the problem.
I have written a small executable using blkid low-level probing, and I have tested it works well from udev rules.
Code: Select all
//gcc -Wall -o blkid-lowlevel blkid-lowlevel.c `pkg-config --cflags --libs glib-2.0 blkid`
//Above is the command to compile this file
/*
* blkid-lowlevel
* Uses low-level superblock probing
*/
#include <blkid.h>
#include <glib.h>
#include <stdio.h>
gint main(gint argc, gchar *argv[])
{
GError *error = NULL;
GOptionContext *context = g_option_context_new(" [DEVICE1] [DEVICE2] ...");
g_option_context_set_summary(context, "This uses blkid low-level prober which bypasses cache");
g_option_context_parse(context, &argc, &argv, &error);
if (error)
{
g_error("%s", error->message);
}
gint i;
for (i = 1; i < argc; i++)
{
blkid_probe probe = blkid_new_probe_from_filename(argv[i]);
if (! probe)
{
g_warning("Couldn't open %s, %s will not be scanned",
argv[i], argv[i]);
continue;
}
blkid_do_safeprobe(probe);
gint j, num_tags;
num_tags = blkid_probe_numof_values(probe);
printf("%s: ", argv[i]);
for (j = 0; j < num_tags; j++)
{
gchar *name, *value;
blkid_probe_get_value(probe, j, (const gchar **) &name,
(const gchar **) &value, NULL);
printf("%s="%s" ", name, value);
}
puts("");
blkid_free_probe(probe);
}
return 0;
}
Is that an alternative to cddetect-quick? Or is it more? Or less?
Do you know a good gtkdialog program? Please post a link here
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
If cddetect-quick also uses ioctl(), then it is exactly equivalent, neither more, nor less. I cannot get more info using ioctl than cddetect-quick does.disciple wrote:Is that an alternative to cddetect-quick? Or is it more? Or less?
Audio cds are currently detected like this:
Code: Select all
// plugins/cdrom.c:456
//Check for audio CD
gint fd = open(volume->unix_dev, O_NONBLOCK | O_RDWR);
if (fd >= 0)
{
if (ioctl(fd, CDROM_DISC_STATUS, 0) == CDS_AUDIO)
{
disk->audio_cd = TRUE;
volume->flags &= (~PUP_VOLUME_IS_MOUNTABLE);
}
close (fd);
}
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
I observe a strange problem when I try to start the daemon from a script inside /etc/init.d . It doesn't detect optical drives when started like that.
Optical drives are detected by iterating over each device in /sys/block, testing each device whether it's an optical drive.
I wonder what is the circumstance when scripts at /etc/init.d are launched.
Starting the daemon from /root/.xinitrc solves the problem but the daemon is killed when X exits. The daemon is meant to continue running even after exiting x.
Optical drives are detected by iterating over each device in /sys/block, testing each device whether it's an optical drive.
I wonder what is the circumstance when scripts at /etc/init.d are launched.
Starting the daemon from /root/.xinitrc solves the problem but the daemon is killed when X exits. The daemon is meant to continue running even after exiting x.
Why don't you start it as a service, but indirectly, with a wrapper script to wait until X starts, but then on a restart of X you may be faced with your initial problem...
Puppy Linux Blog - contact me for access
What is the failure mode?akash_rawal wrote:It doesn't detect optical drives when started like that.
How do you do the test?Optical drives are detected by iterating over each device in /sys/block, testing each device whether it's an optical drive.
They are launched by /etc/rc.d/rc.services, in the background, in alphabetical order. /etc/rc.d/rc.services in turn is launched by /etc/rc.d/rc.sysinit; rc.sysinit is launched by /sbin/init --- and that is as early as you get. Before /sbin/init we're talking about initramfs (ie, before the pup.sfs is loaded and executed).I wonder what is the circumstance when scripts at /etc/init.d are launched.
I have no problems detecting the device type: "cat /sys/block/sr0/device/type" returns 5 (which means read-only device - see here for example http://lkml.indiana.edu/hypermail/linux ... /1295.html) even in initramfs.
But of course this depends on when the driver for the particular device is loaded - if the driver is not built into kernel (compiled as a module instead), depending on when the module gets loaded, the device may not be ready for detection in rc.sysinit. In particular, if it is loaded dynamically by udev (udev is started early in rc.sysinit), it may take a while before it appears in /sys/block (that is, after all the udev rules for it are processed). USB devices are particularly prone to this additional delay.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
Well I got the problem.
The problem was that environment variable LD_LIBRARY_PATH wasn't set.
And what's worse is that pup-volume-monitor uses LD_LIBRARY_PATH to search for its plugins. That means the cdrom plugin simply wasn't loaded!
The fix is simple then. Just set LD_LIBRARY_PATH variable.
The problem was that environment variable LD_LIBRARY_PATH wasn't set.
And what's worse is that pup-volume-monitor uses LD_LIBRARY_PATH to search for its plugins. That means the cdrom plugin simply wasn't loaded!
The fix is simple then. Just set LD_LIBRARY_PATH variable.
Last edited by akash_rawal on Fri 08 Jun 2012, 15:33, edited 1 time in total.
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
The mechanism is translated from /lib/udev/rules.d/50-udev-default.rules.jamesbond wrote:How do you do the test?Optical drives are detected by iterating over each device in /sys/block, testing each device whether it's an optical drive.
Code: Select all
# cdrom
SUBSYSTEM=="block", KERNEL=="sr[0-9]*", SYMLINK+="scd%n", GROUP="cdrom"
SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="4|5", GROUP="cdrom"
KERNEL=="pktcdvd[0-9]*", GROUP="cdrom"
KERNEL=="pktcdvd", GROUP="cdrom"
Code: Select all
gboolean pup_drive_test_optical(struct udev_device *dev)
{
gboolean result = FALSE;
if (strstr(udev_device_get_sysname(dev), "sr")
|| strstr(udev_device_get_sysname(dev), "pktcdvd"))
result = TRUE;
if (!result)
{
const gchar *type = udev_device_get_sysattr_value(dev, "device/type");
if (type)
{
if ((type[0] == '4') || (type[0] == '5'))
result = TRUE;
}
}
return result;
}
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
I hope now pup-volume-monitor is stable enough to move it to additional software section?
http://www.murga-linux.com/puppy/viewtopic.php?t=78881
http://www.murga-linux.com/puppy/viewtopic.php?t=78881
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
I quickly wrote an implementation for desktop drive icons for desktops that do not support them. It uses GIO.
It can be configured to stick to a corner of the screen, align icons vertically, change font colors, etc. Settings take effect immediately.
Icons look like rox-filer icons for a while, till you move mouse pointer over it.
Could anyone package this, I myself am running out of time. My school will be reopening next week and I have to rush through my holiday hw for summer vacations before that.
It can be configured to stick to a corner of the screen, align icons vertically, change font colors, etc. Settings take effect immediately.
Icons look like rox-filer icons for a while, till you move mouse pointer over it.
Could anyone package this, I myself am running out of time. My school will be reopening next week and I have to rush through my holiday hw for summer vacations before that.
- Attachments
-
- desktop_drive_icons-0.0.1.tar.gz
- (124.61 KiB) Downloaded 505 times
this is very nice drive icon. the labels are very helpful because i prefer look at the label than sda3 or sda4 like that. can anyone compile that in lupu, dpup, or slacko? i tried to compile myself but didn't result anything.
but nothing happened.
thank you.
Code: Select all
./configure
make
make install
thank you.
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
Run this:
after installing.
Code: Select all
desktop_drive_icons
- MinHundHettePerro
- Posts: 852
- Joined: Thu 05 Feb 2009, 22:22
- Location: SE
Hello !
I must be a bit on the daft side
However I compile and run it, I get Where should I put the what-named config file - and what should the contents be?
Cheers /MHHP
I must be a bit on the daft side
However I compile and run it, I get
Code: Select all
# desktop_drive_icons
** Message: Config file not found
^C
#
Cheers /MHHP
[color=green]Celeron 2.8 GHz, 1 GB, i82845, many ptns, modes 12, 13
Dual Xeon 3.2 GHz, 1 GB, nvidia quadro nvs 285[/color]
Slackos & 214X, ... and Q6xx
[color=darkred]Nämen, vaf....[/color] [color=green]ln -s /dev/null MHHP[/color]
Dual Xeon 3.2 GHz, 1 GB, nvidia quadro nvs 285[/color]
Slackos & 214X, ... and Q6xx
[color=darkred]Nämen, vaf....[/color] [color=green]ln -s /dev/null MHHP[/color]
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
You don't need to worry about it at all. Desktop-drivre-icons will automatically generate it when you change a setting.MinHundHettePerro wrote:Hello !
I must be a bit on the daft side
However I compile and run it, I getWhere should I put the what-named config file - and what should the contents be?Code: Select all
# desktop_drive_icons ** Message: Config file not found ^C #
Cheers /MHHP
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
Desktop-drive-icons has been moved here : http://www.murga-linux.com/puppy/viewto ... 792#632792.