Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Mon 23 Apr 2018, 09:56
All times are UTC - 4

 Forum index » Taking the Puppy out for a walk » Suggestions
Rewriting pup_event in C
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 6 of 7 [99 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7 Next
Author Message
amigo

Joined: 02 Apr 2007
Posts: 2641
PostPosted: Sun 13 May 2012, 13:14    Post subject:  
I didn't but quickly uploaded it here:
http://distro.ibiblio.org/amigolinux/download/Utils/autorun-3.20/

Here's the command I use to start it (from Window Maker's 'autostart' script):
Code:

autorun --notify-insert="/usr/bin/rox /mnt/cdrom" --cdplayer="/usr/bin/wmcdplay" --recorder="/usr/bin/simplecdrx" --interval=2000 &


There's an archive of patches there you'll want to pay attention to. If you use src2pkg, you should be able to use my autorun.src2pkg script there to build it -otherwise, have a look at it to see the commands used to build it. I created the patches to address some issues with the build (on an older system gcc-3.4.6/glibc-2.3.6), so your mileage may vary.

You could start it during the init scripts, but it is best to start it (backgrounded) after the desktop is up and running. Either way, the code may prove valuable to the OP -although it is written in C++ (Drat it!)

As I mentioned, CD/DVD hardware doesn't issue any kind of signal which would generate a kernel event -you have to poll the drive for any changes and each poll cycle has to be complete. Basicallly, you check the drive to see if there is a disk in there. If not, you go to the next polling loop. If there is a disk, then you have to determine the type -if it has a filesystem you mount it, if it is an audio disc you run the player, otherwise it is a blank disk and you run the burner. You *could* use another method where you'd eject the disk once during bootup, then close the door -that way you'd at least know if the door is open or closed before staring to poll it.

About autorun: as the name suggests, it was meant to provide the functionality provided by Windows when an autorun.inf file is present, but I don't use it for that.

I'm also interested to know what udev rule the OP is using to generate the kernel add/change events -maybe newer kernel drivers are somehow polling the drives automatically?
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL
PostPosted: Sun 13 May 2012, 18:41    Post subject:  
akash_rawal wrote:
If you do manage to generate udev events for optical drives, it will be detected as an internal hard drive or usb flash drive.

You won't have options like ejecting and loading the tray till the support for optical drives is added.


Ejecting and autorunning the appropriate media player is handled by the mount script I'm using.

I am generating the udev events by leaving the probe-optical function in pup_event_frontend_d. That part works fine.

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.

Anyway I'm looking forward to updates. Having a working volume monitor is a huge usability improvement for Saluki.
_________________
http://saluki-linux.com
Back to top
View user's profile Send private message Visit poster's website 
jamesbond

Joined: 26 Feb 2007
Posts: 3146
Location: The Blue Marble
PostPosted: Mon 14 May 2012, 07:38    Post subject:  
amigo wrote:
I didn't but quickly uploaded it here:
http://distro.ibiblio.org/amigolinux/download/Utils/autorun-3.20/

Here's the command I use to start it (from Window Maker's 'autostart' script):
Code:

autorun --notify-insert="/usr/bin/rox /mnt/cdrom" --cdplayer="/usr/bin/wmcdplay" --recorder="/usr/bin/simplecdrx" --interval=2000 &

Thanks amigo - I'd like to look at this.

jemimah wrote:

I am generating the udev events by leaving the probe-optical function in pup_event_frontend_d. That part works fine.

pup_event_frontend_d calls cddetect_quick to do this - so this is the same way I'm doing it. My code looks like this
Code:
awk '/^drive name:/ { for (i = 3; i <= NF; i++) print "/dev/" $i; exit }' /proc/sys/dev/cdrom/info |
xargs -n 1 cddetect_quick -d > /dev/null
I'm calling it once every 5 seconds (5 seconds is about the time required for DVD drive to settle when you insert a new disc anyway). I used patched cddetect_quick; the original one from
Barry returns 255 for anything other than "disc inserted" and that stops xargs from continuing (the patched version returns 1 instead).
_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
Back to top
View user's profile Send private message 
akash_rawal

Joined: 25 Aug 2010
Posts: 232
Location: ISM Dhanbad, Jharkhand, India
PostPosted: Sat 19 May 2012, 12:59    Post subject:  
jemimah wrote:

akash_rawal wrote:
If you do manage to generate udev events for optical drives, it will be detected as an internal hard drive or usb flash drive.

You won't have options like ejecting and loading the tray till the support for optical drives is added.


Ejecting and autorunning the appropriate media player is handled by the mount script I'm using.

Well, I meant by using GIO API.
Code:

gboolean            g_volume_can_eject                  (GVolume *volume);
void                g_volume_eject                      (GVolume *volume,
                                                         GMountUnmountFlags flags,
                                                         GCancellable *cancellable,
                                                         GAsyncReadyCallback callback,
                                                         gpointer user_data);
gboolean            g_volume_eject_finish               (GVolume *volume,
                                                         GAsyncResult *result,
                                                         GError **error);


Anyways the plugin support is requiring a major rewrite, it will take time.

I found libburn, but it is absent in lucid puppy:
Code:

# pkg-config --modversion libburn-1 
Package libburn-1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libburn-1.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libburn-1' found
#
Back to top
View user's profile Send private message 
akash_rawal

Joined: 25 Aug 2010
Posts: 232
Location: ISM Dhanbad, Jharkhand, India
PostPosted: Sat 19 May 2012, 13:09    Post subject:  
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.

Do you manage to get udev or kernel events for opening and closing tray? If no, that could be the problem.

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.
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL
PostPosted: Fri 25 May 2012, 11:49    Post subject:  
akash_rawal wrote:
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.

Do you manage to get udev or kernel events for opening and closing tray? If no, that could be the problem.

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.


AFAIK the opening/closing the tray doesn't generate udev events.
_________________
http://saluki-linux.com
Back to top
View user's profile Send private message Visit poster's website 
akash_rawal

Joined: 25 Aug 2010
Posts: 232
Location: ISM Dhanbad, Jharkhand, India
PostPosted: Wed 06 Jun 2012, 15:47    Post subject:  
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.
Code:

# 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)


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.
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3146
Location: The Blue Marble
PostPosted: Wed 06 Jun 2012, 22:13    Post subject:  
akash_rawal wrote:
Currently it can detect only upto audio cds, and that too I haven't tested yet. I don't have any.
You can make one. Get a few mp3 and use pburn to make an audio cd of them Cool
_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
Back to top
View user's profile Send private message 
akash_rawal

Joined: 25 Aug 2010
Posts: 232
Location: ISM Dhanbad, Jharkhand, India
PostPosted: Thu 07 Jun 2012, 01:15    Post subject:  
Thanks, you helped me find a bug which actually filtered out audio cds.

I was uselessly checking for presence of filesystem Embarassed

I have fixed the bug, and added a more descriptive error message.
Back to top
View user's profile Send private message 
akash_rawal

Joined: 25 Aug 2010
Posts: 232
Location: ISM Dhanbad, Jharkhand, India
PostPosted: Thu 07 Jun 2012, 02:52    Post subject:  
jemimah wrote:
akash_rawal wrote:
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.

udev removes the entire environment , including PATH variable. You have to re-export it yourself or use full path to blkid.


It's not a PATH issue. Blkid correctly returns info about every drive except the one in question. It's bizarre.


Is this because blkid executable uses high-level probing, while I use low-level probe?
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:

//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;
}
Back to top
View user's profile Send private message 
disciple

Joined: 20 May 2006
Posts: 6781
Location: Auckland, New Zealand
PostPosted: Thu 07 Jun 2012, 03:42    Post subject:  
Is that an alternative to cddetect-quick? Or is it more? Or less?
_________________
If you have or know of a good gtkdialog application, please post a link here

Classic Puppy quotes

ROOT FOREVER
Back to top
View user's profile Send private message 
akash_rawal

Joined: 25 Aug 2010
Posts: 232
Location: ISM Dhanbad, Jharkhand, India
PostPosted: Thu 07 Jun 2012, 04:03    Post subject:  
disciple wrote:
Is that an alternative to cddetect-quick? Or is it more? Or less?

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.

Audio cds are currently detected like this:
Code:
// 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);
   }
Back to top
View user's profile Send private message 
akash_rawal

Joined: 25 Aug 2010
Posts: 232
Location: ISM Dhanbad, Jharkhand, India
PostPosted: Fri 08 Jun 2012, 02:55    Post subject:  
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.
Back to top
View user's profile Send private message 
01micko


Joined: 11 Oct 2008
Posts: 8670
Location: qld
PostPosted: Fri 08 Jun 2012, 07:08    Post subject:  
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... Confused
_________________
Puppy Linux Blog - contact me for access
Back to top
View user's profile Send private message Visit poster's website 
jamesbond

Joined: 26 Feb 2007
Posts: 3146
Location: The Blue Marble
PostPosted: Fri 08 Jun 2012, 08:07    Post subject:  
akash_rawal wrote:
It doesn't detect optical drives when started like that.
What is the failure mode?

Quote:
Optical drives are detected by iterating over each device in /sys/block, testing each device whether it's an optical drive.
How do you do the test?

Quote:
I wonder what is the circumstance when scripts at /etc/init.d are launched.
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 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/kernel/0602.1/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, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 6 of 7 [99 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Suggestions
Jump to:  


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group

[ Time: 0.0843s ][ Queries: 13 (0.0160s) ][ GZIP on ]