View Single Post
Old 12-10-2012, 07:43 PM   #818
eureka
but forgot what it's like
eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.
 
Posts: 741
Karma: 2345678
Join Date: Dec 2011
Location: north (by northwest)
Device: Kindle Touch
Quote:
Originally Posted by dave2008 View Post
In fact, the reason why I use raw value is I don't know it can be constructed in that way ;P Now I know it, thanks. I tried your patch and it compiles without any error even though ioctl.h is not included (at least I cannot find it in the build environment). That's strange...
There is #include <sys/ioctl.h> in einkfb.c, so host system ioctl.h is used in compilation. Full chain is sys/ioctl.h -> bits/ioctl-types.h -> asm/ioctls.h -> asm-generic/ioctls.h -> linux/ioctl.h -> asm/ioctl.h -> asm-generic/ioctl.h -> _IOW found. Don't know, whether it's OK or bad (to use host system ioctl.h header)...

Quote:
Originally Posted by dave2008 View Post
But the real problem is the actual size of mxcfb_update_data51 is 0x4c here, not 0x48 (mxcfb_update_data is also 4 bytes larger). I double checked the definition of the structure, it is the same as the one in geekmaster's video player. Any thought?
Ha-ha, really size is 0x4c. I didn't even try to calculate real size, just checked that other components are exactly the same.

It means, one 4-byte field is superfluous.

Here is definition of mxcfb_alt_buffer_data from include/linux/mxcfb.h from 5.3.0 kernel source:
Code:
struct mxcfb_alt_buffer_data {
  __u32 phys_addr;
  __u32 width;  /* width of entire buffer */
  __u32 height;  /* height of entire buffer */
  struct mxcfb_rect alt_update_region;  /* region within buffer to update */
};
UPD: I also think that it's better to rename mxcfb_update_data51 to mxcfb_update_data and current mxcfb_update_data to mxcfb_update_data_50x (or to something like this) and add comment to mxcfb_update_data_50x (about it's validity only in 5.0.x firmwares). And add MXCFB_SEND_UPDATE_50X for usage with mxcfb_update_data_data_50x. Reason: KPV doesn't have legacy of supporting 5.0.x and, probably, will never have, so suffix 51 is excessive.

Last edited by eureka; 12-10-2012 at 08:05 PM. Reason: cosmetic fixes
eureka is offline   Reply With Quote