Guest ejtagle Posted February 8, 2012 Report Share Posted February 8, 2012 You'd think so eh .. but for some reason this repo is not recognising itself as a git one ... no git commands work ;) No matter .. new AOSP compiling now .. see in a couple of hours what happens ... EDIT :- HQ video now works .. many a wasted hour on a dirty AOSP build ... picture looks very nice ... also just noticed transparency effect in the notification popups .. very swish .. we never had that before ... Just testing sleep right now ... on the inital tests it appears to work ... just needs longer rest and a check for wakelocks before i can say all is well ... but on the upshot right now im very happy ... a little more work to the build after this and ill release it .. Its nearly there .... :) There is an small secret here, Cass... Most kernels 2.6.39 out there were based on my initial port of drivers from the 2.6.36 kernel... Initially. and the 2.6.36 kernel was configured this way, the framework buffer was configured to run at 16bits per pixel (65k colors)... But, as we were trying with you to sort out the video acceleration issues, at some time i upped the bits per pixel to 32 and enabled error difussion dithering. The kernel you are using is configured in that way, but most other kernel (Adam included) are still using 16bits ... If you think about it, 32bits sounds too much, for an LCD that is just able to use 18 bits per pixel... But, i found out that the Tegra2 does not work that way. Tegra2 emulates the missing bits by using dynamic error diffusion dithering, effectively reaching at least 24 bit color on the 18bit LCD. But, if i reduce the framebuffer bpp to 16 bits, then there are no extra bits to perform dithering... So, our current 32bit bpp gives us way better picture quality that Adam or the others... And i am perfectly able to tell the difference.. You will also notice it when there are alpha channel based transitions, colors seem to fade very nicely... And also all the color interpolations look really nice... Not to mention video playback ;) Link to comment Share on other sites More sharing options...
Guest Cass67 Posted February 8, 2012 Report Share Posted February 8, 2012 There is an small secret here, Cass... Most kernels 2.6.39 out there were based on my initial port of drivers from the 2.6.36 kernel... Initially. and the 2.6.36 kernel was configured this way, the framework buffer was configured to run at 16bits per pixel (65k colors)... But, as we were trying with you to sort out the video acceleration issues, at some time i upped the bits per pixel to 32 and enabled error difussion dithering. The kernel you are using is configured in that way, but most other kernel (Adam included) are still using 16bits ... If you think about it, 32bits sounds too much, for an LCD that is just able to use 18 bits per pixel... But, i found out that the Tegra2 does not work that way. Tegra2 emulates the missing bits by using dynamic error diffusion dithering, effectively reaching at least 24 bit color on the 18bit LCD. But, if i reduce the framebuffer bpp to 16 bits, then there are no extra bits to perform dithering... So, our current 32bit bpp gives us way better picture quality that Adam or the others... And i am perfectly able to tell the difference.. You will also notice it when there are alpha channel based transitions, colors seem to fade very nicely... And also all the color interpolations look really nice... Not to mention video playback ;) Ohh yeah :) ... The HQ video is nothing short of stunning on the YouTube stream so Amen to that ... Though is it limitation of the Adam screen that limits the PQ? Those chaps have 32bpp enabled also ... Cheers Cass Link to comment Share on other sites More sharing options...
Guest brucelee666 Posted February 9, 2012 Report Share Posted February 9, 2012 (edited) Ohh yeah :) ... The HQ video is nothing short of stunning on the YouTube stream so Amen to that ... Though is it limitation of the Adam screen that limits the PQ? Those chaps have 32bpp enabled also ... Cheers Cass Cass, Ha Ha guess instead of posting boot image and links should have just said do a clean build and problems would have been solved ;) Glad you got everything solved. Re. Adam looking at adam gpu and fb_data still says 16-bit per pixel so I don't think they are using 32-bit. edit:- forget adam comment looking at DHD branch they changed fb_data to 32- originally looking at different branch Edited February 9, 2012 by brucelee666 Link to comment Share on other sites More sharing options...
Guest Cass67 Posted February 9, 2012 Report Share Posted February 9, 2012 Re. Adam looking at adam gpu and fb_data still says 16-bit per pixel so I don't think they are using 32-bit. This commit suggests they are .. though .. this is one part of the puzzle .. where is fb_data ? https://github.com/EnJens/android-tegra-nv-2.6.39/commit/746ebbce4dd5f37e790a6de62a32edae409b87b1 Cheers Cass Link to comment Share on other sites More sharing options...
Guest ejtagle Posted February 9, 2012 Report Share Posted February 9, 2012 (edited) Ohh yeah :) ... The HQ video is nothing short of stunning on the YouTube stream so Amen to that ... Though is it limitation of the Adam screen that limits the PQ? Those chaps have 32bpp enabled also ... Cheers Cass No , they could also use it... They never merged the patch (at least, EnJens github does not have it... Even HDMI seems to be in 16bit in their ROM) ... In some way, could be my fault... As i don't use git in my own development cycle, i don't tag commits, so no change history... It is very common for me to be developing without inet access, so git is not as useful ... Besides, sometimes i have to do several tests to find working fixes, and git commits/reverts would just slow down them.. I find git more useful when following a development/review plan, or when working in groups... ;) edit1: on the rel14-merge they use 16bit for HDMI, 32bit for fb, and ordered dithering (TEGRA_DC_ORDERED_DITHER () .. But tegra supports error diffusion ... There was an error in the comments ;) ... Edited February 9, 2012 by ejtagle Link to comment Share on other sites More sharing options...
Guest pischla Posted February 9, 2012 Report Share Posted February 9, 2012 Cass, is the internal GPS and 3g modem in my PoV Mobii supposed to work in the alpha 2 build? You guys are doing an amazing job by the way, making these great devices even greater! Link to comment Share on other sites More sharing options...
Guest Cass67 Posted February 9, 2012 Report Share Posted February 9, 2012 Cass, is the internal GPS and 3g modem in my PoV Mobii supposed to work in the alpha 2 build? Don't think it does, i don't have one to test with it but chaps over on TR were working on it .. i think the last i noticed it failed to work ... Alpha 3 / Beta1 whatever i call it will have the files to support it but the Vega has no means to allow me to test ... ill leave that fun up to the likes of you ;) Cheers Cass Link to comment Share on other sites More sharing options...
Guest ejtagle Posted February 9, 2012 Report Share Posted February 9, 2012 Don't think it does, i don't have one to test with it but chaps over on TR were working on it .. i think the last i noticed it failed to work ... Alpha 3 / Beta1 whatever i call it will have the files to support it but the Vega has no means to allow me to test ... ill leave that fun up to the likes of you ;) Cheers Cass I do have a PoV mobii with 3G and GPS... I think that applying the same patches that the Adam guys did, but using the huawei-ril lib with the appropiate entry in the init.rc script should be enough. Regarding the GPS, the lib i posted for ICS should be enough ;) Link to comment Share on other sites More sharing options...
Guest wooshy1 Posted February 10, 2012 Report Share Posted February 10, 2012 No , they could also use it... They never merged the patch (at least, EnJens github does not have it... Even HDMI seems to be in 16bit in their ROM) ... In some way, could be my fault... As i don't use git in my own development cycle, i don't tag commits, so no change history... It is very common for me to be developing without inet access, so git is not as useful ... Besides, sometimes i have to do several tests to find working fixes, and git commits/reverts would just slow down them.. I find git more useful when following a development/review plan, or when working in groups... ;) edit1: on the rel14-merge they use 16bit for HDMI, 32bit for fb, and ordered dithering (TEGRA_DC_ORDERED_DITHER () .. But tegra supports error diffusion ... There was an error in the comments ;) ... I have been experimenting with the 32bit depth for a while now on the .36 kernel and this is the only way to stabilise the stock browser on honeycomb obviously as you have already mentioned this significantly increase the video/image quality however you must also increase the amount of gpu ram. I have currently got it set at 184mb with 5mb fb1 and 8mb hdmi 720p fb which is stable I think we may be able to reduce it a little more yet. regarding gpu ram I looked at the xoom, tf and streak 7 kernels to see how they have done it. the xoom kernel goes about gpu ram by using the low memory for main system ram and the himem for gpu ram giving it 512mb for main ram and 512mb for gpu ram it also has 8mb for fb1 and 16mb for 1080p hdmi fb. the tf kernel has 768mb for main ram and 256mb for gpu ram and the same as the xoom for both the framebuffers. both the tf kernel and xoom kernel have 32bit depth on internal and hdmi fb's. This is ok if you have 1gb of ram which we do NOT so I looked to the dell streak 7 kernel which is a ventanna tablet with 512mb ram and an official honeycomb update. the way dell have achieved this is by cheating in my opinion ;) they have reduced the screen resolution to 800x480 used 16bit depth for internal fb and 24bit depth for hdmi. All this allows the streak to have 128mb gpu ram leaving 384mb for system ram 2mb for fb1 and strangely only 2mb for hdmi even though at 24bit depth and 720p it should need a bigger fb than this. With this tied together with the android low memory killer settings allows honeycomb to run very well if a little sluggish at times on the streak. now comes the problem I cannot get the initlogo.rle to display correctly with the 32bit depth enabled the image is displayed with garbled colours and it is display twice in the top half of the screen and the bottom half is just black and white lines. I have tried using a black image and an image produced at 32bit depth to no avail. Any pointers here would be helpful. I assume the frameworks in android are optimized for either 16bit depth or 32bit depth that is why when 32bit depth is enabled alot of problems go away and considering we are essentially emulating a xoom as both the ICS build and honeycomb are based on xoom/tf targets. Also I did notice that before nvidia introduced the seperate dc/fb driver they allowed the lcd resolution to be different from the framebuffer resolution and the driver would stretch it to fill the screen, I did try to get this working in the new driver but I do not think they have fully implemented the functionality. again any pointers on the is would be great. great work cass and eduardo I really cant wait to have ago with your latest efforts for both the .39 kernel and ICS. please correct me if I am wrong on any of the above. ok this has been a long post but just one more thing. Cass will you be publishing the device profile for ICS so anyone can build from aosp when you have got it working I would like to give it ago but my build keeps failing in libmedia cant remember the error for now but was just wondering? thanks again guys/gals your work is much appreciated. Link to comment Share on other sites More sharing options...
Guest Cass67 Posted February 10, 2012 Report Share Posted February 10, 2012 Cass will you be publishing the device profile for ICS so anyone can build from aosp when you have got it working I would like to give it ago but my build keeps failing in libmedia cant remember the error for now but was just wondering? Hi Wooshy .. Yes ill publish it as soon as i have a build im happy with and make it shuttle'centric ... currently i build it as moto/wingray with customizations to suit us then after the system folder is created i move stuff over that we need, libs, apks etc ... im too lazy right now to update the profile to suit every time i make a change, its not stable enough right now ;) Shouldnt be long .. The build is looking quite good right now .. just trying to sort out a lingering wifi issue where it stops scanning and you cant add a new AP .. had many a complaint about it in earlier alphas but now im seeing it for myself for some reason .. If you like i can tar up what i have and mail it to you ? PM your mail addy if you'd like this meanwhile... Cheers Cass Link to comment Share on other sites More sharing options...
Guest Cass67 Posted February 10, 2012 Report Share Posted February 10, 2012 (edited) I do have a PoV mobii with 3G and GPS... I think that applying the same patches that the Adam guys did, but using the huawei-ril lib with the appropiate entry in the init.rc script should be enough. Regarding the GPS, the lib i posted for ICS should be enough ;) In which case the framework is there for all this to work, i just need to check the patches the Adam chaps applied to make sure we're in sync... :) edit - Ok, i see the changes in the android side for 3g, simple enough .. though im a bit confused as to whether we need them .. seems the Adam chaps have a new ril that requires the renaming of the rmnet interface to wwan0, we however remain with the ril lib we have always had .. which uses rmnet ... the changes to Android are cosmetic and im not sure we need them ... What you think, am i missing something ? edit 2 - also .. do me a favour .. can you look to the camera lib and see if there is any potential issues with the new gfx drivers or kernel .. driver loads ok for me but apps fc as soon as they use it .. http://pastebin.com/Y5jCN6Pt /dev/input/* has proper permissions and should be able to open the device ok .... Cheers Cass Edited February 10, 2012 by Cass67 Link to comment Share on other sites More sharing options...
Guest DrMon Posted February 10, 2012 Report Share Posted February 10, 2012 (edited) With regards to the PCM audio issues you gentlemen were having before, did you ever sovlve them with that patch? I dived a little deeper into the dma system and found we are quite short of channels. There are 16 for Tegra 2, 4/5 of which seemed to be reserved for the AVP, 4 SPI devices using 2 channels each, 1 uart device using 2 channels which leaves 1 channel left, which we usually use for playing back sound. However, trying to record often involves pressing a button which in itself plays a sound, hence the "Out of memory" errors we're encountering. I guess the important question here is - do we need all 4 SPI devices? Edited February 10, 2012 by DrMon Link to comment Share on other sites More sharing options...
Guest the_corvus Posted February 10, 2012 Report Share Posted February 10, 2012 In which case the framework is there for all this to work, i just need to check the patches the Adam chaps applied to make sure we're in sync... :) edit - Ok, i see the changes in the android side for 3g, simple enough .. though im a bit confused as to whether we need them .. seems the Adam chaps have a new ril that requires the renaming of the rmnet interface to wwan0, we however remain with the ril lib we have always had .. which uses rmnet ... the changes to Android are cosmetic and im not sure we need them ... What you think, am i missing something ? edit 2 - also .. do me a favour .. can you look to the camera lib and see if there is any potential issues with the new gfx drivers or kernel .. driver loads ok for me but apps fc as soon as they use it .. http://pastebin.com/Y5jCN6Pt /dev/input/* has proper permissions and should be able to open the device ok .... Cheers Cass Hi boys... Be carefull with 3G, in ICS there is some changes that needs to modify huaweigeneric.c, I cant get it to work in wetab, but i'm almost here. Can you point me to the sources of Adams ril? Thanks Corvus. Link to comment Share on other sites More sharing options...
Guest Borkata Posted February 10, 2012 Report Share Posted February 10, 2012 In which case the framework is there for all this to work, i just need to check the patches the Adam chaps applied to make sure we're in sync... :) edit - Ok, i see the changes in the android side for 3g, simple enough .. though im a bit confused as to whether we need them .. seems the Adam chaps have a new ril that requires the renaming of the rmnet interface to wwan0, we however remain with the ril lib we have always had .. which uses rmnet ... the changes to Android are cosmetic and im not sure we need them ... What you think, am i missing something ? edit 2 - also .. do me a favour .. can you look to the camera lib and see if there is any potential issues with the new gfx drivers or kernel .. driver loads ok for me but apps fc as soon as they use it .. http://pastebin.com/Y5jCN6Pt /dev/input/* has proper permissions and should be able to open the device ok .... Cheers Cass In our previous kernels interface for 3G was usb0, but now we have usb0 and it chooses wwan0 for interface name. About the new ril lib we using the difference from the old one made for GB and HC is that there is implementation for GW and DNS handling. To make 3G working I need also to make proper permissions to the serials of the modem (other way is to give correct permissions to rild). Link to comment Share on other sites More sharing options...
Guest Cass67 Posted February 10, 2012 Report Share Posted February 10, 2012 Hi boys... Be carefull with 3G, in ICS there is some changes that needs to modify huaweigeneric.c, I cant get it to work in wetab, but i'm almost here. Can you point me to the sources of Adams ril? Thanks Corvus. Cant be 100%, but it looks to be this one... Borkata can advice if this is not the case... https://github.com/rrathi/adamICS/commit/72953f13ef0a3eccd03d772045789dd0e1e9d090 I only noticed they had one while sifting through the overlay stuff to see what changed ... :) Cass Link to comment Share on other sites More sharing options...
Guest Borkata Posted February 10, 2012 Report Share Posted February 10, 2012 Cant be 100%, but it looks to be this one... Borkata can advice if this is not the case... https://github.com/r...5789dd0e1e9d090 I only noticed they had one while sifting through the overlay stuff to see what changed ... :) Cass Yes this is the new mbm-ril :) Link to comment Share on other sites More sharing options...
Guest the_corvus Posted February 10, 2012 Report Share Posted February 10, 2012 Yes this is the new mbm-ril :) Thanks... But my modem is a Huawei :( Corvus. Link to comment Share on other sites More sharing options...
Guest Borkata Posted February 10, 2012 Report Share Posted February 10, 2012 Thanks... But my modem is a Huawei :( Corvus. You can ask DerArtem or even look at his device tree https://github.com/DerArtem/android_device_toshiba_betelgeuse since we talked about how to enable 3G for Folio using huaweigeneric-ril. Link to comment Share on other sites More sharing options...
Guest ejtagle Posted February 10, 2012 Report Share Posted February 10, 2012 (edited) With regards to the PCM audio issues you gentlemen were having before, did you ever sovlve them with that patch? I dived a little deeper into the dma system and found we are quite short of channels. There are 16 for Tegra 2, 4/5 of which seemed to be reserved for the AVP, 4 SPI devices using 2 channels each, 1 uart device using 2 channels which leaves 1 channel left, which we usually use for playing back sound. However, trying to record often involves pressing a button which in itself plays a sound, hence the "Out of memory" errors we're encountering. I guess the important question here is - do we need all 4 SPI devices? We use i2c devices .. SPI is not used ... at least on shuttle. I think there is no need to enable all SPI channels... ;) The out of memory errors were caused, at least with shuttle, because we were using a wrong block size ... We do get audio recordings, but they seem to be garbled... sometimes... :o .. We didn't get Out of memory errors with the latest audio_hw_primary i posted here. The Adam version is based on my previous version of audio_hw_primary that did not had those fixes... Unifying the sampling rate between capture and playback is needed (even the codec does not suport different sampling rates between play and record channels) ... I'd suggest to compare them and port the changes, as they are minimal ... ;) Edited February 10, 2012 by ejtagle Link to comment Share on other sites More sharing options...
Guest ejtagle Posted February 10, 2012 Report Share Posted February 10, 2012 (edited) In which case the framework is there for all this to work, i just need to check the patches the Adam chaps applied to make sure we're in sync... :) edit - Ok, i see the changes in the android side for 3g, simple enough .. though im a bit confused as to whether we need them .. seems the Adam chaps have a new ril that requires the renaming of the rmnet interface to wwan0, we however remain with the ril lib we have always had .. which uses rmnet ... the changes to Android are cosmetic and im not sure we need them ... What you think, am i missing something ? edit 2 - also .. do me a favour .. can you look to the camera lib and see if there is any potential issues with the new gfx drivers or kernel .. driver loads ok for me but apps fc as soon as they use it .. http://pastebin.com/Y5jCN6Pt /dev/input/* has proper permissions and should be able to open the device ok .... Cheers Cass I see: E/CameraHardware( 103): Unable to power camera E/V4L2Camera( 103): ERROR opening V4L interface: Permission denied E/CameraHardware( 103): cannot open device. I think we have permission problems on the Camera power control ;) - The /sys/shuttle-pm-camera/power_on entry.. It is 0666 , but perhaps the /sys is forbidding writes ... edit1: Ok, we have no permission problems on the Camera power control, the problem is we can't open /dev/video0 . Perhaps a permission problem, or perhaps a rule is missing.. D/EventHub( 153): No input device configuration file found for device 'USB 2.0 Camera'. I/EventHub( 153): New device: id=6, fd=260, path='/dev/input/event5', name='USB 2.0 Camera', classes=0x80000001, configuration='', keyLayout='/system/usr/keylayout/Generic.kl', keyCharacterMap='/system/usr/keychars/Generic.kcm', builtinKeyboard=false I/InputReader( 153): Device added: id=6, name='USB 2.0 Camera', sources=0x00000101 Seems to be recognizing the camera as a keyboard ;), instead of creating the /dev/video0 entry ;) -- If you do echo "1" >/sys/shuttle-pm-camera/power_on , the camera should power on and the /dev/video0 should appear Edited February 10, 2012 by ejtagle Link to comment Share on other sites More sharing options...
Guest ejtagle Posted February 10, 2012 Report Share Posted February 10, 2012 I have been experimenting with the 32bit depth for a while now on the .36 kernel and this is the only way to stabilise the stock browser on honeycomb obviously as you have already mentioned this significantly increase the video/image quality however you must also increase the amount of gpu ram. I have currently got it set at 184mb with 5mb fb1 and 8mb hdmi 720p fb which is stable I think we may be able to reduce it a little more yet. regarding gpu ram I looked at the xoom, tf and streak 7 kernels to see how they have done it. the xoom kernel goes about gpu ram by using the low memory for main system ram and the himem for gpu ram giving it 512mb for main ram and 512mb for gpu ram it also has 8mb for fb1 and 16mb for 1080p hdmi fb. the tf kernel has 768mb for main ram and 256mb for gpu ram and the same as the xoom for both the framebuffers. both the tf kernel and xoom kernel have 32bit depth on internal and hdmi fb's. This is ok if you have 1gb of ram which we do NOT so I looked to the dell streak 7 kernel which is a ventanna tablet with 512mb ram and an official honeycomb update. the way dell have achieved this is by cheating in my opinion ;) they have reduced the screen resolution to 800x480 used 16bit depth for internal fb and 24bit depth for hdmi. All this allows the streak to have 128mb gpu ram leaving 384mb for system ram 2mb for fb1 and strangely only 2mb for hdmi even though at 24bit depth and 720p it should need a bigger fb than this. With this tied together with the android low memory killer settings allows honeycomb to run very well if a little sluggish at times on the streak. now comes the problem I cannot get the initlogo.rle to display correctly with the 32bit depth enabled the image is displayed with garbled colours and it is display twice in the top half of the screen and the bottom half is just black and white lines. I have tried using a black image and an image produced at 32bit depth to no avail. Any pointers here would be helpful. I assume the frameworks in android are optimized for either 16bit depth or 32bit depth that is why when 32bit depth is enabled alot of problems go away and considering we are essentially emulating a xoom as both the ICS build and honeycomb are based on xoom/tf targets. Also I did notice that before nvidia introduced the seperate dc/fb driver they allowed the lcd resolution to be different from the framebuffer resolution and the driver would stretch it to fill the screen, I did try to get this working in the new driver but I do not think they have fully implemented the functionality. again any pointers on the is would be great. great work cass and eduardo I really cant wait to have ago with your latest efforts for both the .39 kernel and ICS. please correct me if I am wrong on any of the above. ok this has been a long post but just one more thing. Cass will you be publishing the device profile for ICS so anyone can build from aosp when you have got it working I would like to give it ago but my build keeps failing in libmedia cant remember the error for now but was just wondering? thanks again guys/gals your work is much appreciated. Tegra2 hw only supports 16 and 32bit per pixel framebuffers. HDMI is always 32bit: The tegra2 driver ignores the bitdepth specified for that framebuffer. But, it must be taken info account when computing the hdmi framebuffer memory... the main framebuffer requires 2 video pages to work reliably under Android, the HDMI i am not sure... Probably with some apps (full screen vieo playback), 2 HDMI pages would also be required... Probably, the initlogo.rle requires a 16bit framebuffer... Or it assumes so... Did you try to compress a 32bit logo ? ... If you are unable to make it work, tell me, i will write an small logo display utility... or you could do something along the lines : zcat logo.gz > /dev/fb0 ;) You don't need such huge amount of gpu memory... mount debugfs. then cat /dbgfs/nvmap/ ... To check exactly how much vide memory a given program is using ;) -- Link to comment Share on other sites More sharing options...
Guest ejtagle Posted February 10, 2012 Report Share Posted February 10, 2012 Whaty about HDMI audio ? -- Did it work ? -- Seems that if it does not, the required mods to make it work are trivial... I will try to test it, but feel free to also test it and tell me if it does not work ;), so we can fix it Link to comment Share on other sites More sharing options...
Guest ejtagle Posted February 10, 2012 Report Share Posted February 10, 2012 You can ask DerArtem or even look at his device tree https://github.com/D...hiba_betelgeuse since we talked about how to enable 3G for Folio using huaweigeneric-ril. Yes, i do agree ... ;) -- I think i have the PDF describing the huawei AT command set ... Will post it later, if it helps Link to comment Share on other sites More sharing options...
Guest Cass67 Posted February 10, 2012 Report Share Posted February 10, 2012 I see: E/CameraHardware( 103): Unable to power camera E/V4L2Camera( 103): ERROR opening V4L interface: Permission denied E/CameraHardware( 103): cannot open device. I think we have permission problems on the Camera power control ;) - The /sys/shuttle-pm-camera/power_on entry.. It is 0666 , but perhaps the /sys is forbidding writes ... edit1: Ok, we have no permission problems on the Camera power control, the problem is we can't open /dev/video0 . Perhaps a permission problem, or perhaps a rule is missing.. D/EventHub( 153): No input device configuration file found for device 'USB 2.0 Camera'. I/EventHub( 153): New device: id=6, fd=260, path='/dev/input/event5', name='USB 2.0 Camera', classes=0x80000001, configuration='', keyLayout='/system/usr/keylayout/Generic.kl', keyCharacterMap='/system/usr/keychars/Generic.kcm', builtinKeyboard=false I/InputReader( 153): Device added: id=6, name='USB 2.0 Camera', sources=0x00000101 Seems to be recognizing the camera as a keyboard ;), instead of creating the /dev/video0 entry ;) -- If you do echo "1" >/sys/shuttle-pm-camera/power_on , the camera should power on and the /dev/video0 should appear Yes, perfect thanks a lot, never dawned on me to check the power... one more thing off the list ;) echo 1 > /sys/devices/platform/shuttle-pm-camera/power_on chmod 666 /dev/video0 did the trick ... cant remember having that in previous releases, for camera at least ... Cheers Cass Link to comment Share on other sites More sharing options...
Guest ejtagle Posted February 10, 2012 Report Share Posted February 10, 2012 Yes, perfect thanks a lot, never dawned on me to check the power... one more thing off the list ;) echo 1 > /sys/devices/platform/shuttle-pm-camera/power_on chmod 666 /dev/video0 did the trick ... cant remember having that in previous releases, for camera at least ... Cheers Cass of course you don't want to put echo 1 > /sys/devices/platform/shuttle-pm-camera/power_on everytime the device boots, or the camera will be kept powered on .. I think when the /dev/video0 entry is created, the right permissions should be set ;) Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now