The SX1 IS Porting Thread - page 17 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 ... 12 13 14 15 16 [17] 18 19 20 21 22 ... 39   Go Down

The SX1 IS Porting Thread

  • 381 Replies
  • 172173 Views
*

Offline reyalp

  • ******
  • 14080
Re: The SX1 IS Porting Thread
« Reply #160 on: 18 / April / 2009, 03:48:56 »
Advertisements
Quote from: fboesch on 18 / April / 2009, 03:32:16
Question(s): If one has a fix: How can we check in the changes? Just post a diff here? Or are there some members to be adressed directly?
Post a patch here.

Quote
Second: How is it when changes to CHDK code itself are suggested, regarding a "Check-In"?  Changes there will have an impact on the build for EVERY cam ... how is there the "Quality Assurance" Process?
What's this "Quality Assurance" you speak of ? :P

More seriously, if it's something that will affect all cameras, we build the all the builds and maybe try to get a few different cameras tested before checking in (e.g. one of each os and processor). How much testing is done depends on the scope and risk of the change. Because of the number of unique platforms, QAing CHDK is a tough problem and we don't really have a good solution.

Quote
Background --> As assumed earlier: The Zebra & Edge Overlay functions (for the SX1) needs to be "fixed" within the CHDK code to support two different "Screen Widths". As far as I know: No other Cam has this "feature" for now. On all other Cam's the Display Height&Width will stay the same. Not so with the SX1. So I'm actually looking for a clear Params Value (within SX1) showing the Display-Mode (Wide <-> Normal) so that this change of status could be used in the corresponding code, to adjust the Edge- or Zebra Overlay. OR alternative: To add a "prelimenary check" & adjustment in the code of CHDK so that later Edge-/Zebra-Drawing is using the right coordinates.
SD990 will need code to deal with the viewport and bitmap not being the same width. However, it doesn't change on the fly.

Some cameras already change viewport height between play and record mode (sd/ixus mostly)
Logged
Don't forget what the H stands for.
*

Offline fboesch

  • ***
  • 105
Re: The SX1 IS Porting Thread
« Reply #161 on: 18 / April / 2009, 03:59:41 »
Quote from: PhyrePhoX on 17 / April / 2009, 18:17:46
btw regarding the fi2 problem: reyalp had the idea to maybe reverse engineer the official 2.0 fi2 update to find out what is different.

The more "insights" the better it is...

Just my current status of investigations regarding "Boot/Fi2":  Diskbook.bin method works generally fine, however: sometimes also this method CHDK does not start on my SX1...then the Cam will be ready (without CHDK) very fast...as if the Cam did not inspect the inserted (& write protected) SD Card long enough/did not find the "diskboot.bin" file (--> internal Card-Reader was not yet ready)...this may be an issue already in the built-in firmware, but it may impact also a FI2 update... So my thoughts: I would like to "delay" the boot sequence used by CHDK a little bit...just to make sure that eventually the internal communication between Program <-> "card-reader" is ok...
Logged
*

Offline fboesch

  • ***
  • 105
Re: The SX1 IS Porting Thread
« Reply #162 on: 18 / April / 2009, 04:05:16 »
Quote from: reyalp on 18 / April / 2009, 03:48:56

SD990 will need code to deal with the viewport and bitmap not being the same width. However, it doesn't change on the fly.

Some cameras already change viewport height between play and record mode (sd/ixus mostly)

Hmmm...interesting...Thx! ...and this seems to be the point: The SX1 does change the viewport "on-the-fly" during Rec mode...and this is not yet handled within Edge/Zebra Code...they get the viewport value (once) out of the definition (camera.h) as I think...right?
Logged
*

Offline reyalp

  • ******
  • 14080
Re: The SX1 IS Porting Thread
« Reply #163 on: 18 / April / 2009, 04:31:47 »
I wonder if the delay loop in loader\<platform>\entry.S after turning off sd card power needs to be longer for digic 4 ?

The zebra code gets viewport height each time gui_osd.c:gui_osd_draw_zebra() is called. The width is set at startup by gui_draw.c: draw_init(). It also assumes that the bitmap and viewport width are the same. The whole thing is a bit of a mess, which is one reason I've been putting off tackling it for sd990.
Logged
Don't forget what the H stands for.
*

Offline fboesch

  • ***
  • 105
Re: The SX1 IS Porting Thread
« Reply #164 on: 18 / April / 2009, 05:18:05 »
Quote from: reyalp on 18 / April / 2009, 04:31:47
I wonder if the delay loop in loader\<platform>\entry.S after turning off sd card power needs to be longer for digic 4 ?

The zebra code gets viewport height each time gui_osd.c:gui_osd_draw_zebra() is called. The width is set at startup by gui_draw.c: draw_init(). It also assumes that the bitmap and viewport width are the same. The whole thing is a bit of a mess, which is one reason I've been putting off tackling it for sd990.

Larger Delay Loop: Yes - this is at the current stage - what my guts (stomache) say would be worth to check...

Zebra: Yes, I've seen it (code looks good). BUT: The "on-the-fly" change of aspect is done within the SX1 on a later stage (live picture shown finally on the LCD)....I will make some Pictures of the Screen (with Zebra on) to show, what I mean (especially Zebra Mode is helpful, because in Wide-View it works 100% correctly. But switching to "normal" view for standard 4:3 pictures (black bars on left and right of the largescreen SX1 LCD) will also show the Zebra area...but this blinking area is not on the shown "object" but blinking on the left side of it. Interesting detail: The "shift" to the left of the Zebra area seems to be the width of one black side-bar...).

So what I meant by enhancing the code:

1) Get the knowledge in which "mode" the Cam is operating (whereas "Mode" is meant "Display Screening" not a Cam Mode)
2) Do on-the-fly a "correctiv" value addition on "Width" Value (depending on Screen Mode)

:)
Logged
*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: The SX1 IS Porting Thread
« Reply #165 on: 18 / April / 2009, 07:43:50 »
all the time i try to prevent fi2 from being built on the autobuild server, but of course this doesnt work - the autobuild always sets the OPT_FI2 flag regardless of whats in the makefile.inc, so our patch was only working locally :D
i dont know how to prevent fi2 creation, unless i hack the makefile, which i dont wanna do. well, maybe fboesch will solve the fi2 problem :)
Logged
*

Offline pev69

  • **
  • 55
Re: The SX1 IS Porting Thread
« Reply #166 on: 18 / April / 2009, 08:01:06 »
I think I found out how to see from code if the camera is set to wide or standard aspect ratio: propertycase 294 seems to be 1 when set to wide and 0 when standard. So now if somebody would like to bother with the zebra and edge overlay code :). Well, a CAM_HAS_VARIABLE_ASPECT or similar flag should also be added to compile-time definitions (include\camera.h), if it does not already exist.
« Last Edit: 18 / April / 2009, 08:42:51 by pev69 »
Logged
*

Offline fboesch

  • ***
  • 105
Re: The SX1 IS Porting Thread
« Reply #167 on: 18 / April / 2009, 10:13:06 »
Quote from: pev69 on 18 / April / 2009, 08:01:06
I think I found out how to see from code if the camera is set to wide or standard aspect ratio: propertycase 294 seems to be 1 when set to wide and 0 when standard. So now if somebody would like to bother with the zebra and edge overlay code :). Well, a CAM_HAS_VARIABLE_ASPECT or similar flag should also be added to compile-time definitions (include\camera.h), if it does not already exist.


EXCELLENT, pev69! Actually it should be enough to be able to read out a clear Yes or No / 0 or 1! 

--> I think it is now possible to calculate the "correction value" for drawing based on this:

(just a raw outline of how i would approach to correct the drawing)

------
if propcase294=0 then
 
ShiftDrawingBy =  (LCDwidth - (LCDwidth/16*12)) / 2 

else

ShiftDrawingBy = 0


What I suggest is to calculate how much pixels (value) need to be added to the coordinates when starting to draw the Zebra area. And because the shift of the Zebra area is just one of the black bars (width) I use above formula to calculate (based on the given Input of the Width at 16:9). This is the value, which should be ADDED to the Drawing Routine later, so that the Zebra area is drawn correctly onto the shown over-exposured object seen on the LCD. And only do this, if the "Normal" Mode is activated. As we know: in Wide Mode it is working already fine!

This may help the EdgeOverlay function too then...

Due to the fact, that I'm not a Developer...(yeah...in older times I could program assembler & Delphi) it may take a little bit more time until really implemented :-) (ps.fi2 is more important to me....right now (after swapping my SD cards) CHDK does also not start from my 1GB Card either...now just compiling the latest trunk743...hope that fresh copy of files will help....


NEWS EDIT: I was lucky to see on the screen that just correct the drawing, would not really be the remedy, but has to do with a different start adress to read the "screenbuffer"...

--> Blinking area of the "live picture on the screen" is shifted as ususal to the "left". But this time on the "right" of the overexposured object there was also a blinking area, which was actually a "Left-Over" from a Capture just BEFORE! So the Zebra stuff needs to be told, that if the SX1 is in a different view-mode (life picture), it should not change the Drawing, but READ from the correct memory area! :-)
« Last Edit: 18 / April / 2009, 10:30:18 by fboesch »
Logged
*

Offline fboesch

  • ***
  • 105
Re: The SX1 IS Porting Thread
« Reply #168 on: 18 / April / 2009, 10:14:21 »
Quote from: PhyrePhoX on 18 / April / 2009, 07:43:50
all the time i try to prevent fi2 from being built on the autobuild server, but of course this doesnt work - the autobuild always sets the OPT_FI2 flag regardless of whats in the makefile.inc, so our patch was only working locally :D
i dont know how to prevent fi2 creation, unless i hack the makefile, which i dont wanna do. well, maybe fboesch will solve the fi2 problem :)



Well...Now compiling Trunk743 gives me some very interesting errors.txt...but

A) it will compile
B) FI2 is NOT generated/included in the SX1 ZIP

So I think it works (until Fix has been found?)
« Last Edit: 18 / April / 2009, 10:38:04 by fboesch »
Logged
*

Offline pev69

  • **
  • 55
Re: The SX1 IS Porting Thread
« Reply #169 on: 18 / April / 2009, 11:32:39 »
I tested by modifying the Zebra code so that it shifts the outgoing buffer address by exactly as you described above (albeit overstricken text, heh) (simplified, the required shift comes to exactly 1/8 of the screen width :)) when the propertycase is 0.

Works great, althought there's still some strangeness in the use of the screen buffers, which shows as garbage over the black sidebars when the zebra is drawn, if started with 4:3 aspect. But when the zebra has been active once in the 16:9 mode, after that there's no more garbage in the 4:3 mode either.

I still don't understand what is the difference between the "viewport" and the screen. Now the heights are viewport 270 and screen 240 (width is same 480 for both), but it does not effect the zebra at all (i.e. no need for vertical shifting/scaling). And when I added a condition that it does not draw anything after the screen height (240) has been reached (in the original zebra code the y-loop goes from 1 to the viewport height, 270), the zebra is still drawn nicely throughout the whole screen. ??
« Last Edit: 18 / April / 2009, 11:35:09 by pev69 »
Logged
Pages: 1 ... 12 13 14 15 16 [17] 18 19 20 21 22 ... 39   Go Up
« previous next »
 

Related Topics