Status on the m5602
This are the issues I'm currently working on with the m5602:
1) Removing the in kernel frame format conversion and frame resizing
Doing format conversion and resizing in the kernel is bad, as many drivers typically want to do the same kind of conversion this is better put in a user-space library.
Hans de Goede has developed the libv4l and I'm currently experimenting with it.
I have a local branch working quite fine with some applications and the image quality is better than with my own homebrewed in-kernel algorithms. One big problem that many v4l2-apps have bugs in them requiring patching for them to work with libv4l. As some applications are dead upstream (I'm looking at you XawTV) there are going to be some compatibility issues.
Another issue is that in-kernel frame resizing won't be supported as we need to bayer-decode before doing a frame resize.
A main goal is to get skype working with libv4l as this is heavily requested by the community, but so far I haven't got it working. I'm currently discussing this issue with Hans and hope that it's resolveable.
2) Sorting out the s5k83a, s5k4aa mess
I've been collecting usb snoops from various people with samsung sensors in hope of adding support for more machines. The current support is not good as it only covers a subset of cameras and with varying degrees of success. My current work flow has been to gather snoops and produce init sequences for different machines and letting the snoop submitter testing them out. S o far the success rate has been low and I'm currently trying to figure out why it doesn't work.
Initially my assumptions were that only one samsung sensor was used, the s5k83a, later research indicate the we're (at least) having two different sensors with the s5k4aa as the second. They seem to be somewhat similiar in setup but I think that we'll be best off having two different sensor setups for them both. The biggest issue is the lack of datasheets for these chips, making it almost impossible to figure out what the register writes are doing.
I have tried to request datasheets from Samsung but am sofar unsuccessful.
3) Reverse-engineering the actual m5602-chip
There haven't been much progress on this front. I know at least have a lot of different dumps from different sensors which gives more information on how to configure the chip. Trouble is that the most configuration seem static over the whole range of chips with no information on how to change frame encoding or frame size.
1) Removing the in kernel frame format conversion and frame resizing
Doing format conversion and resizing in the kernel is bad, as many drivers typically want to do the same kind of conversion this is better put in a user-space library.
Hans de Goede has developed the libv4l and I'm currently experimenting with it.
I have a local branch working quite fine with some applications and the image quality is better than with my own homebrewed in-kernel algorithms. One big problem that many v4l2-apps have bugs in them requiring patching for them to work with libv4l. As some applications are dead upstream (I'm looking at you XawTV) there are going to be some compatibility issues.
Another issue is that in-kernel frame resizing won't be supported as we need to bayer-decode before doing a frame resize.
A main goal is to get skype working with libv4l as this is heavily requested by the community, but so far I haven't got it working. I'm currently discussing this issue with Hans and hope that it's resolveable.
2) Sorting out the s5k83a, s5k4aa mess
I've been collecting usb snoops from various people with samsung sensors in hope of adding support for more machines. The current support is not good as it only covers a subset of cameras and with varying degrees of success. My current work flow has been to gather snoops and produce init sequences for different machines and letting the snoop submitter testing them out. S o far the success rate has been low and I'm currently trying to figure out why it doesn't work.
Initially my assumptions were that only one samsung sensor was used, the s5k83a, later research indicate the we're (at least) having two different sensors with the s5k4aa as the second. They seem to be somewhat similiar in setup but I think that we'll be best off having two different sensor setups for them both. The biggest issue is the lack of datasheets for these chips, making it almost impossible to figure out what the register writes are doing.
I have tried to request datasheets from Samsung but am sofar unsuccessful.
3) Reverse-engineering the actual m5602-chip
There haven't been much progress on this front. I know at least have a lot of different dumps from different sensors which gives more information on how to configure the chip. Trouble is that the most configuration seem static over the whole range of chips with no information on how to change frame encoding or frame size.
posted by Erik Andrén Zachrisson at 11:20 PM
1 Comments:
hi, I think I discovered I have an S5K4AA sensor. Whom to mail for requesting the Datasheet? Should it be publicly available or must be bought?
Post a Comment
<< Home