Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

And let us not forget the requested bug-reports. I just remembered myself.....

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

While a clever idea, IMO this shouldn't be a obvious setting in the UI or forced on everyone. Overclocking the device in applications is a blocker.
This would potentially make camera-ui2 depend on KP too which isn't a good idea.
I think it needs more thought, myself.

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

I didn't ever suggest doing an entry in the GUI. It would just tempt to break sth :)

The idea is that the power users could edit the scripts to do some power behavior ;)

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Already there:

https://gitorious.org/community-ssu/...i-set-priority

https://gitorious.org/community-ssu/...erface.c#L1079

https://gitorious.org/community-ssu/...erface.c#L1116

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Nice to see mister freemangordon and the rest of the gang still doing work like this. Respect! And if I can help somehow, I'm here. ;)

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

I pretty much like the idea, it makes for a nice generic interface to provide a thing commonly known as "hooks" and not really all that new (see http://mfnboer.home.xs4all.nl/twinkl...l#call_scripts for a pretty convenient reference implementation that I co-designed and recommend. sorry for the URL not really working, click on "Manual" and then on "Call Scripts") and it is independant of platform specifics like d-bus etc while still allowing to interface to those specific mechanisms with simple shellscript oneliners like "dbus-send"

Obviously you want to configure the full path&name of hook scripts inside the app via a user interface or config file of known name (or even direct gconf meddling though that again is platform specific dependency to gconf available), and you want to call such script with a rich environment(!) on every moderately relevant event like focus engage, focus release, trigger, app start, app close, review/gallery-open, gallery-close with delete, gallery-close w/o delete, a.s.o. And you frequently want the camera app to base further behaviour on return codes of the script called (given there exists such script to call) to e.g. close the cam app when the photo taken is ok by any postprocessing done in the hook - again see twinklephone for reference implementation.


I can see a few more nice usecases than just "enable/stop OC". E.G. how about uploading (in case of video, even streaming?) any media capture into "the cloud" so it's safe form any attempt to delete the record on device - I bet you know what I'm talking about.
Same scenario: make the camera automatically start video capture when camdoor gets opened while lens NOT pointing down to the floor, while when lens points down to the floor then the flashlight gets started and cam-app closed.
All of the above can easily get achived with a few lines in shellscripts doing the right thing when called by camera app

cheers
jOERG

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Please help! Urgent!
Is it possible to disable flash LED on N900 altogether while taking photos? It might save my freedom and even life.
Police forces brought to Kiev from East represent, protect and work with mafia. They break a lot of laws themselves, shoot journalists, beat medics/red cross representatives, force official hospitals to pass injured to them without any treatment.
Please! ASAP!

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

int_ua,
the most reliable measure is to cover flash/privacy-LED with 3 layers of black sticky tape.
I just checked the CSSU "nikocam" (comes with CSSU-T) and it allows to disable flash, but still "flashes" the red tiny LED when taking a photo.
I can't come up with reliable better suggestions right away. rmmod adp1653 might help but I don't know what side effects and how reliable.

Good luck, take care!
jOERG

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

If making a video is acceptable solution then starting recording via icon on screen (not hw button - it triggers autofocus which turns on white LEDs on low light!) while covering camera hole with hand and then disabling the red LED with live focus ( http://maemo.org/packages/view/lfocus/ ) might work.

Be safe!

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Use FCAMERA (NOT Bless) to take pictures. I justed tested it and it did not use the flash for focus. and use the tape as suggested by joerg.

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Works for me - neither white nor red LED flashes.

It uses RGB LED instead, flashing purple color for a split second, but it might be effect of some custom configuration and it's hardly noticable even when looking directly at screen turned on.

FCamera might also be a good choice because of storing TIFFs instead of JPEGs - photos don't show up in image gallery!

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

this might help too, haven't tried it though...
http://talk.maemo.org/showthread.php?t=86285

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

kernel-power have sysfs entry allowing to *completely* disable red "privacy" led, no matter of circumstances (so, it won't work, even when application try to light up this led explicitly, like Lanterne for it night-vision friendly torch):

Remember, you need Pali's kernel-power (in reasonably recent version, like not something 2 years old) for it to work, and it reset itself on reboot. Personally, I've this one-liner as script inside /etc/event.d/, so it sets itself automatically on every boot.

As for flash led, there is an option to disable it in camera-ui preferences - those two things combined worked for me in otherwise risky situations, but, in life-threatening ones, mechanical methods - like sticking it with tape - might be the most reliable thing.

/Estel

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Sometimes, settings (for example white balance) are not saved between sessions, still trying to figure why...

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

According to:
http://talk.maemo.org/showpost.php?p...postcount=1674

...and:
http://talk.maemo.org/showpost.php?p...postcount=1675

...it seems that we actually have specialist(s?) interested in maintaining camera-ui FOSS replacement. That's great news! To celebrate it (and as an answer to request), I want to collect info about every bug/issue with replacement camera-ui (as opposed to stock camera-ui), test reproducibility on two devices (my daily one, and another one freshly reflashed with CSSU-Thumb *only*), and finally, post every and each one on bugs.maemo.org.

For this, I need your help - if you had buggy experiences with camera-ui replacement - even if your posts about it are burier somewhere in this long thread - please, repost it now. I'm dully noting everything on my todo-test lists. Input greatly appreciated.

Cheers,
/Estel

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

I remember camera-ui2 sometimes hung when recording a long 720p video. The preview became black and after some time it couldn't be stopped. You had to kill camera-ui2 and then recover the video.

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

I noticed that many "random" (i.e. non 100% reproducible) bgs are hard to report properly, due to complete lack of any logging in camera-ui(2) that I'm aware of. Is attaching gdb only way to obtain meaningful log, or there is some other mechanism that I'm not aware of?

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

I'd love to know this

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Hi All!

I would be appreciate any help or advice for the following issue: I just installed latest CSSU stable on my freshly reflashed n900 and camera features are not available. I checked, it still runs camera-ui instead of camera-ui2.
My question: am I able to install camera-ui2 manually (from xterm of course...)? If yes, how should I do that; I mean: do I have to remove camera-ui first, or just apt-get camera-ui2...?
Sorry if I ask dumb question but I'm trying CSSU for the first time.

Thanks,

jm

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

AFAIK camera-ui(2) is available only for CSSU-Testing (or thumb), while you're using CSSU-Stable. You have to either switch to -Testing for this particular feature (and quite a bunch of other ones) - which is preferred way - or install camera-ui from CSSU-Testing separately - including all it's possible dependencies - creating some kind of hybid CSSU-Stable/Testing variant on your device.

I wouldn't recommend the latter, if you're not familiar with how repository system works in GNU/Linux -related operating systems. Not to mention that if you are familiar with it, there is no reason to use CSSU-Stable at first place...

/Estel

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Thanks for your reply Estel!

I will consider installing CSSU-Testing... :)

jm

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Thank you Estel for taking care of the bug reports.
I had some problems which were reported by other users here, but I don't know if they are solved because I use the stock camera. If they are not, I hope they will be soon :)

Last time I tried to record a video (two years ago), camera-ui2 became frozen. I was not able to kill him, I had to reboot my phone and the video was irrecoverable. But this happened only when I was trying to record something outside, after 5-15 minutes, and not when I tested it at home for 20 minutes (but nothing was moving in the front of the camera).
Since I installed the stock camera-ui after all updates, when I needed it.

And last time I tried it, it took more than 5 sec for launching it after having opened the camera cover. This is the most annoying bug for me.

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Hi , all who have tried camera ui 2 have experienced problems
So i propose to make it a standalone app that we can install and use it until it will be stable , meantime for important events we use the stock camera !

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Btw. any progress on the bug report of freezing, reported by me?

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Hello can we get this app in the catalogues for easy installation?

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

1- you have to download Faster App Manager
2- add cssu catalog to FAM
3- open install apps
4- in category choose all packages(advanced)
5- then search for camera ui
6- after you find it , install it

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

If remember correctly I once had downloaded camera-ui2 .deb file from somewhere in this forum to use it with 720p codecs.

edit:
I will suggest you to install CSSU-Thumb. Its very stable and improves performance+battery life a lot.

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Hello again
The default camera and the new camera ui takes images at 2576x1936 pixels
According to nokia aka microsoft http://www.microsoft.com/en-gb/mobil...pecifications/
the sensor has 2584x1938 pixels
The photos taken by Bless have 2592x1968 pixels
How about making cameraui2 to use the full resolution of the sensor ?!

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

don't know if it is related, but I found at least one bug (in HD video recording), will upload in cssu-devel shortly

EDIT:
http://talk.maemo.org/showpost.php?p...&postcount=424

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Its 2584x1938 - 2576x1936 = 20656 pixels more, so 20656/4987136 = 0.00414 = 0.414% (approx.) more pixels if we used the full sensor capacity. Why should we care then?

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Well it is 2592x1968 - 2576x1936 = 5101056 - 4987136 = 113920 so
113920 / 4987136 = 0.02284 = 2.3%(approx.)
But for me it's not a matter of why we care & why we don't care , I think it more simple : it is there so why don't we make it as an option ?!

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

@UJKU: but we can't capture more than the sensor can capture, can we?

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Cost (of the coding) vs benefit (as seen in images).

Methinks Cost outweighs the other.

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Yeah we cant but the sensor must be bigger than that nokia reports because if you take a picture with bless n900 you will see the resolution that i described

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Yeah we can analyze it further and see who is bigger but since most of the coders here works for free , i just wanna it to throw this idea , if someone is interested in working on it ! this may be an interesting feature to add in the cameraui2 and is plus when comaring it to stock camera

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

I would rather have better pictures than more pixels. So if "someone" (it's always "someone", isn't it, never "me") wants to work on it, then they can spend their time better on things like removing the quality cap, as suggested earlier.

CCD sensor manufacturers cover their bums by specifying "effective" or "save" image dimensions that are on the order of about 5 pixels smaller on each side than the whole sensor. This is to allow for compensating various manufacturing faults that are most prominent at the edges. Some sensors allow using the full image size, others would not go over the effective size.

I personally think it's not woth it. 0.4% or 2%, you won't see the difference one way or another. Unless there are some bad pixels at the edge, then you will definiteky notice.

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

removing the quality cap is another feature that i want it too
I have used blessn900 and there are not bad pixels ,
It's like the overclocking thing
Just because most of the n900s arent stable ate 1 ghz this should not mean that we cant release an app that offer the possibility
Or the HD recording , normally my n900 would record at 20fps but this doesnt stop fmg from adding it as a feature

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

First of all, bugs need to be fixed. Then maybe some extra functionality.

Re: camera-ui2 (now a part of CSSU) (updated 09. May)
 

Re bugs, and my attempt to collect the and report *proper* way to CSSU bugteam:

I tried it on two devices, one my "usual" everyday one, (thumb), and one freshly flashed (inc. emmc vanilla, which shouldn't be relevant). The 2nd device used cssu-thumb, later I reflashed it to stock again and used cssu-testing, then repeated tests.

On all three devices, I got positive results (aka bugs present) with ALL things reported, at some point, in this thread - including, but not limited to:

*autofocus suddenly becoming slow

* autofocus getting stuck at focusing only up to some random value (for example, few-centimeters - no matter what scene we point it at. When it get's stuck, it clearly *changes* focus, but always device to end up at the same value. Interestingly, value changes between "stuck" accidents, but during same "accident", remains the same.

*camera-ui getting frozen during saving of video, resulting in broken .mp4 container.

*camera-ui crashing randomly

*camera-ui suddenly starting to fail saving most of pictures took

*camera-ui suddenly showing black viewfinder (with all UI elements as they should be, though) and seeming like it "lost contact" with camera hardware (pressing autofocus doesn't move lens, etc) - until restart

*just as above, but with addition of camera-ui window getting clones, and showing proper viewfinder in that clone

...etc. The problem is, that ALL of those issues are not clearly reproducible - they just happen, quite often (especially during longer photo or recording runs - think few hours), if anyone cares to search for them. (I haven't found similar problems in stock camera-ui, when trying to replicate them there).

Now, I wasn't able to find ANY way of getting meaningful logs/debug content from camera-ui. No one who I asked about - including this thread, camera-ui2 thread, and CSSU bugtracker (inside camera-ui reported bug) was able to point me how to get meaningful logs/debug info from camera-ui. I assume that it doesn't have ANY, accessible to average Joe.

This result in complete inability to post a meaningful bug report, that would be anything more than things commented as rants.

Due to this, I'm "officially" giving up on attempts to gather those bugs and report them to bugtracker - at least until some sane way of getting debug output is introduced into camera-ui. If someone more knowledgeable is willing to pick it up, be my guest - it's not a full "rage quit", it's just fact that spending a total of ~90 hours of chasing those bugs, experiencing them, but being unable to report them in a way meaningful to maintainers is too frustrating.

Maybe things like attaching gdb or whatsnot would help, but I have no clue about such things ATM (to the point that I don't even know if it's relevant to this case), and I already spent too much time on this, getting only "worksforme and my girlfriend" answers - despite that reports about camera-ui2 being substandard are numerous (and the links just show a small bite of them).

For now, I'm using a simple hack to have camera-ui (vanilla) for everyday functionality, and run camera-ui2 manually, when I need higher quality video recording (and it's not so important, so I don't fear that it might get corrupted at saving), or some nice functionalities that camera-ui2 offers, like manual focus.

/Estel