GEM-dev May 2011

gem-dev@lists.iem.at

9 participants
21 discussions

bicubic curve
by cyrille henry 21 May '11

21 May '11

hello, i finally had time to work on a new primitive for Gem. I wanted it for almost 10 years! so, i'm glad to present the surface3d that is a bi-cubic curve. it's almost like the curve3d primitive, except that the curve pass throw all control points. (well, i choose not to draw the curve between control point 0 and 1, and control_point_max-1 to control_point_max, because the cubic interpolation is not well defined on this intervals) an other advantage is that this object is not hardware limited for the number of control point. the drawback is that it can be quite slow to compute normals. code is maybe not as clean as one can expect, but it should work. surface3d is on gem svn. any comment are welcome. Cheers Cyrille

3 2

Re: [GEM-dev] trying to access idc1394 camera parameter
by IOhannes m zmölnig 16 May '11

16 May '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/13/2011 08:30 PM, Antoine Villeret wrote: > Hi Iohannes, > > Thanks a lot for thoses tips. > > Since this morning I succeed to make my cam work and to control gain and > shutter. > Unfortunately, the code is very ugly and I didn't use the Properties to hold > the features of the cam. > I just intercept 'set shutter <value>' or 'set gain <value>' messages and > set the corresponding feature. > It's not very useful, but it's enougth for us :-) though i don't know exactly what you do when "intercepting", it feels like this is exactly the reason why the entire properties stuff came into being: allow various devices have a consistent behavior without touching the object the user interacts with (pix_video): in the past those objects have continued to accumulate highly specific messages, which are guaranteed to not work for about 95% of the users. > Moreover, I had some troubles with my Sony XCD-V60 camera. > This cam is IIDC compliant but can sent grey images in 16 bit resolution. > And in the openDevice method, the loop that set the video mode is very > similar to the example provided with libdc1394 ;-) but there is no condition > about the color coding and the loop took the > DC1394_VIDEO_MODE_640x480_MONO16 by default and I think we don't have any > possibilities to set it in PD. With this , the capture setup failed and i if you mean, we don't have the possibilities to use a 16bit greyscale video in Gem right away, then yes. > can't get any image from the camera by default... > I just add a test on color coding and get the best one on > DC1394_VIDEO_MODE_640x480_MONO8 just like in the example ;-); the problem is obviously that the "best" image is very much depending on the use case. in some applications a 1024x768 greyscale image might be preferred over a 640x480 color image, in others it might be the other way round. the use should have the possibility to choose what they think it is best, and they should be able to do so without having to recompile. > Well, just to say that I have what I need for now, but it will be very very > appreciated that all of those things will be implemented soon. I don't think > i will have time to spent on this in before easter so it's up to you ! well, i would say: you should feel free to spend some time in it after easter as well :-) fgamdsr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2mlvUACgkQkX2Xpv6ydvQp1gCfRPdB/rUAe1DjXDW6uyREoL9B Y1UAnRlPycTsvhiotXyw3HGHYNlwVeCC =TYOD -----END PGP SIGNATURE-----

3 2

[ pd-gem-Bugs-3177434 ] deleting a (dc1394) pix_video crash pd
by SourceForge.net 16 May '11

16 May '11

Bugs item #3177434, was opened at 2011-02-10 15:42 Message generated for change (Comment added) made by nusmuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3177434&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pixes (pix_ objects) Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Cyrille Henry (nusmuk) Assigned to: Nobody/Anonymous (nobody) Summary: deleting a (dc1394) pix_video crash pd Initial Comment: using curent svn, if i open pix_video help file with a computer that have no camera, removing pix_video object crash pd. no need to open gemWindows. ---------------------------------------------------------------------- >Comment By: Cyrille Henry (nusmuk) Date: 2011-05-16 13:51 Message: appears to be fixed with current svn (rev 3948) ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-02-11 12:07 Message: even if the problem comes from an invalid device file because you unplugged the fw device, this should not crash Gem. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-02-10 16:11 Message: i realize the crash occur only after having plugged/unplugged the FW device. when removing it, the /dev/raw1394 is still on the file system. the backtrace : (gdb) run Starting program: /usr/local/bin/pd pd/Gem/help/pix_video-help.pd [Thread debugging using libthread_db enabled] open: /etc/pd/gem.conf: No such file or directory open: /home/nusmuk/.pd/gem.conf: No such file or directory open: ./gem.conf: No such file or directory load plugins 'video' in '' pattern : /usr/local/lib/pd/extra/Gem/gem_video*.so dylib loading file '/usr/local/lib/pd/extra/Gem/gem_videoDC1394.so'! dylib loading file '/usr/local/lib/pd/extra/Gem/gem_videoDS.so'! dylib loading file '/usr/local/lib/pd/extra/Gem/gem_videoDV4L.so'! dylib loading file '/usr/local/lib/pd/extra/Gem/gem_videoDarwin.so'! dylib loading file '/usr/local/lib/pd/extra/Gem/gem_videoHALCON.so'! dylib loading file '/usr/local/lib/pd/extra/Gem/gem_videoSGI.so'! dylib loading file '/usr/local/lib/pd/extra/Gem/gem_videoUNICAP.so'! dylib loading file '/usr/local/lib/pd/extra/Gem/gem_videoV4L.so'! dylib loading file '/usr/local/lib/pd/extra/Gem/gem_videoV4L2.so'! dylib loading file '/usr/local/lib/pd/extra/Gem/gem_videoVFW.so'! /dev/video0: No such file or directory [New Thread 0xb7619b70 (LWP 2130)] invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" invalid command name ".x81b2670.c" Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7619b70 (LWP 2130)] gem::video::PIMPL::threadfun (you=0x81a8d50) at video.cpp:189 189 me->m_pimpl->freeze(); (gdb) backtrace #0 gem::video::PIMPL::threadfun (you=0x81a8d50) at video.cpp:189 #1 0x0022596e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x00306a4e in clone () from /lib/tls/i686/cmov/libc.so.6 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-02-10 15:48 Message: you may also use -lib segfault , by matju. it prints a backtrace in the terminal without the need for gdb, and it demangles the C++ symbols as well. it's been posted on pd-list. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-02-10 15:44 Message: could you provide a backtrace of the crash? on linux/osx/similar you can use gdb for producing one: $ gdb -args /path/to/pd -lib Gem -open /my/faulty/patch.pd [...] (gdb) run [... do something to trigger the crasher bug ...] (gdb) backtrace [...] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3177434&group_…

1 0

[ pd-gem-Bugs-3292406 ] pix_snap help patch
by SourceForge.net 10 May '11

10 May '11

Bugs item #3292406, was opened at 2011-04-24 10:56 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: documentation Group: any operating system >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_snap help patch Initial Comment: According to pix_snap's help patch, one would expect that all you need to have pix_snap take a snapshot is to send it a "snap" message at an arbitrary moment, but that won't work. The only way it works, is to send it the snap message just before the gemlist (0 ligical time before), i.e. with a [t a b]. This should definitely be mentioned in the help patch. The current help patch gives no clue that the attached example test_snap.pd won't work and that in order to make it work you need to do like shown in attached test_snap_2.pd The attached file snap_bare_minimum.pd shows the bare minimum (i think) which is needed to succesfully take a snapshot and I think something like this should be shown in the help patch. By the way it would also be worth mentioning that a bang works as a synonim of "snap", though many will guess that. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2011-05-10 12:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-04-26 12:20 Message: sorry, i did not see the DOCUMENTATION flag, apologies for my last comment. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-26 11:49 Message: @nusmuk,: by reporting a bug in the DOCUMENTATION category, I think I only implied that something's wrong with the documentation, not necessarily that something doesn't work. If I misunderstood the correct use of the documentation category and documentation issues are not supposed to be reported in this bugtracker then I apologise ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-04-26 10:28 Message: thanks for the report; i changed the help-patch to be very similar to the [pix_snap2tex] patch, which mentions, that you need something drawn to the framebuffer in order to be happy. this also makes for a more interactive experience :-) ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-04-24 13:34 Message: When reporting a bug, you did imply that things doesn't work. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-24 13:25 Message: That's what I meant, that the help patch misses a lot of information. I didn't mean to imply that pix_snap doesn't work as it should. I am not very good with documentation prose so I don't think I can provide an improved help patch; however I guess the scheme in the attached snap_bare_minimum.pd could be a starting point ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-04-24 12:13 Message: if you look at example 07.texture/07.feedback, you'll notice that pix_snap work if you use [t b a] (and not only [t a b])... if you send color 1 0 0 to the gemwin of your "test_snap.pd", you'll notice that pix_snap does snap a red bufffer : it's because it's working. but when you send a snap message when Gem did not draw an image, the buffer is empty... That is certainly why the help patch says that pix_snap work best in single buffer mode (the buffer is not automatically clear). So, i think pix_snap is working perfectly, but the help patch is clearly missing lot's of information. please, fell free to make a nice help patch that could replace the current one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&group_…

1 0

[ pd-gem-Bugs-3177361 ] no images with FW camera
by SourceForge.net 10 May '11

10 May '11

Bugs item #3177361, was opened at 2011-02-10 14:02 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3177361&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pixes (pix_ objects) Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Cyrille Henry (nusmuk) Assigned to: Nobody/Anonymous (nobody) Summary: no images with FW camera Initial Comment: hello, with Gem svn, ubuntu 10.04 (kernell 2.6.32), and a guppy pro (from AVT) connected with FW800, i can't have images. (same result with a stingray from AVT) the camera create a device /dev/raw1394 and /dev/video1394/0 i've got video plugin dv4l and dc1394. coriender can grab images without any problem. i don't know if it's related, but when creating pix_video object, i've got an error in the terminal : libdc1394 error: Error: Failed to allocate iso bandwidth libdc1394 error: Error: Failed to setup DMA capture ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2011-05-10 11:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-04-26 10:31 Message: i added some "properties" to dc1394, which should allow you to set the operation mode and the iso-speed from within the patch. since i cannot find a dc1394 camera, please test whether this fixesyour problem. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-02-11 11:25 Message: ok, i find the solution. adding : dc1394_video_set_operation_mode(m_dccamera,DC1394_OPERATION_MODE_1394B); before setting speed to 800 solve the problem. so i've go an image. i don't know to make this to work with both FW400 and FW800 device... i still have a small problem : the device is not properly closed. after quitting pd, i have to unpluged it if i want to use it again. (the green led is blinking after closing pd, just like when grabbing is on). ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-02-11 10:56 Message: if i change line 269 of file videoDC1394.cpp from dc1394speed_t speed=DC1394_ISO_SPEED_400; to dc1394speed_t speed=DC1394_ISO_SPEED_800; iv've got more information about why this speed can't be allocated in the terminal : libdc1394 error: An ISO speed >400Mbps was requested while the camera is in LEGACY mode. Please set the operation mode to OPERATION_MODE_1394B before asking for 1394b ISO speeds libdc1394 error: Error: Failed to allocate iso bandwidth libdc1394 error: Error: Failed to setup DMA capture i just don't know how to do that. any help is apreciated in order to make this work for this camera. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-02-10 15:08 Message: well, i did not have other cam connected when i tried this, so pix_video tried all backend at the initialization. so, i now have a v4l device on the computer. when creating pix_video : no messages regarding 1394. (only a message that say pix_video open a v4l2 device). sending driver dc1394 gives in the terminal : libdc1394 error: Error: Failed to allocate iso bandwidth libdc1394 error: Error: Failed to setup DMA capture and in pd log : error videoDC1394: Generic failure: failed to enumerate then, sending device /dev/raw1394 did not change anything. if i do the other order : recreate pix_video, sending device /dev/raw1394, i've got an error that say V4L can not open this device. then sending driver dc1394 print nothing. the camera is in FW800, the computer have only a FW800 port... ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-02-10 14:15 Message: this happens as soon as you create the [pix_video] object? Gem tries to set the bandwidth to 400 when it _open_s the device, but should fall back to whatever the device gives, if FW400 is not supported. but if the problem already occurs when creating [pix_video] (that is: when initializing the dc1394 infrastructure), it will never reach that... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3177361&group_…

1 0

[ pd-gem-Bugs-3292038 ] pix_snap: what does "work best" mean
by SourceForge.net 10 May '11

10 May '11

Bugs item #3292038, was opened at 2011-04-23 15:33 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292038&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: documentation Group: any operating system >Status: Closed Resolution: Duplicate Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_snap: what does "work best" mean Initial Comment: The help patch for pix_snap says: "pix_snap works best with single buffered windows". What does it mean? What are exactly its limitations or known issues with double buffered windows? ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2011-05-10 10:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-04-26 10:15 Message: thanks for your bug-report. it seems that you have already found out what "best" means: in single buffered mode, the buffer you are snapping usually has already some content, whereas in double-buffered mode it is mostly empty (unless you just draw something to it). therefore i tag this issue as "duplicate", as it is basically the same as #3292406 (though from a different pov) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292038&group_…

1 0

[ pd-gem-Bugs-3290926 ] Fails to build with 2.6.38 kernel
by SourceForge.net 05 May '11

05 May '11

Bugs item #3290926, was opened at 2011-04-21 12:31 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3290926&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: linux >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: amoog () Assigned to: Nobody/Anonymous (nobody) Summary: Fails to build with 2.6.38 kernel Initial Comment: The linux kernel 2.6.38 removed support for v4l1, causing a builderror: In file included from pix_video.cpp:18:0: ../Pixes/videoV4L.h:43:29: fatal error: linux/videodev.h: No such file or directory ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2011-05-05 14:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-04-21 13:20 Message: this is fixed in current SVN (for 0.93) if you need to run on 0.92, apply the patch as found here: http://git.debian.org/?p=collab-maint/gem.git;a=commitdiff;h=3ca23072692841… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3290926&group_…

1 0

[ pd-gem-Feature Requests-2827107 ] improve pix_data
by SourceForge.net 02 May '11

02 May '11

Feature Requests item #2827107, was opened at 2009-07-25 19:13 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2827107&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: image processing Group: None >Status: Closed Priority: 5 Private: No Submitted By: Cyrille Henry (nusmuk) Assigned to: IOhannes m zmlnig (zmoelnig) Summary: improve pix_data Initial Comment: pix_data is very usefull, but could be improved : - a quality 1 message could be add in order to set bilinear interpolation - a 32 bit mode could be add in order to read data from a 32 bit framebuffer. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2011-05-02 15:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-04-18 14:47 Message: i've added bilinear interpolation to [pix_data], though i'd rather had [pix_data] be replaced by something like [pix_buffer_peek] (or a "peek" message to [pix_buffer]) ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2009-08-18 14:38 Message: ok, interpolation can be made in the patch, but it would be lot's easier to use it it is in pix_data. It also would be faster. so i think to have a "quality 1" message to pix_data would still be nice. You are right for the framebufer, i'll do another feature request. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-08-10 19:40 Message: bilinear (or whatever) interpolation could be easily done in the patch. as for the other request: [pix_data] does not know anything about framebuffers, but works on pixes, which currently are only 8bit per channel. however, it would be interesting to be able to query pixels of a render-buffer with high-resolution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2827107&group_…

1 0

how to compile GEM objects pix_colortrack & pix_drum
by José Manuel Páez Moncaleano 02 May '11

02 May '11

Hey, I'm worwing with a ps3 Eye in two projects wich requiere objects that where compiled by the author of this projects. This man work with pd and shared the patches. What I want to ask you is how can i compiled this two objects pix_drum and pix-colortrack because on pd it seems like those objects do not exist Thanks

5 5

Using juju firewire stack ?
by gnd＠itchybit.org 02 May '11

02 May '11

Hi, im using Ubuntu 11.04 and just compiled GEM from sources. The old firewire stack was completely removed from this version of the system () however i see in a mail from June 2010 that: > in current trunk there is support for both the traditional DV1394 interface > and the new juju stack ("videoDV4L" > plugin) How can i use this plugin ? With my firewire device connected i cant seem to make it work, no combination of [driver dv( [device /dev/fw1( [driver dv4l( etc .. doesnt work .. Also the compilation was a bit of a pain: - had to remove Pixes/videoV4L.h include from pix_video.cpp - had to move Pixes/videoV4L.cpp away from the Pixes directory - had to edit Pixes/videoV4L2.h adding include <sys/types.h> and include <sys/stat.h> (found that somewhere on the net as a solution for some compilation for maverick) Maybe i should report these somehow differently ? Anyway im really interested in making my dv device work as fast as possible - how can i use it ? This will be helpfull also for the other people who will switch to Natty soon .. thanks a lot, gnd/

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev May 2011