| 00:43.00 | *** join/#htc-linux Rajko (rajkosto@cable-94-189-224-176.dynamic.sbb.rs) |
| 02:21.39 | *** join/#htc-linux surge (surge@pool-98-118-154-23.bflony.fios.verizon.net) |
| 02:35.23 | *** part/#htc-linux Cotulla (~myfakemai@109.205.253.11) |
| 03:06.55 | *** join/#htc-linux rajkosto (~rajkosto@wan.rajkonet.info) |
| 03:17.49 | *** join/#htc-linux d3tul3 (~detule@unaffiliated/d3tul3) |
| 05:35.58 | *** join/#htc-linux ccxCZ (~ccxCZ@156.200.broadband11.iol.cz) |
| 06:41.24 | *** join/#htc-linux Ondalf (~ondalf@cable-roi-50ddf8-39.dhcp.inet.fi) |
| 06:51.44 | *** join/#htc-linux eR^zeRa` (~zzeratul@ip-84-42-202-42.net.upcbroadband.cz) |
| 07:06.42 | *** join/#htc-linux kiozen (~kiozen@p578a42db.dip0.t-ipconnect.de) |
| 07:40.58 | *** join/#htc-linux stroughtonsmith (~steven@86-42-135-220-dynamic.b-ras1.bbh.dublin.eircom.net) |
| 08:15.24 | *** join/#htc-linux DuperMan (Duper@46-116-177-82.bb.netvision.net.il) |
| 08:31.26 | *** join/#htc-linux arif-ali (~arif-ali@81.144.163.60) |
| 08:49.01 | *** join/#htc-linux noobhands (d03032a2@gateway/web/freenode/ip.208.48.50.162) |
| 08:49.14 | noobhands | https://i.chzbgr.com/maxW500/6769628928/hFB022C10/ |
| 09:10.11 | *** join/#htc-linux nrirclog (~nrirclog@jongkorendijk.nl) |
| 10:24.15 | *** join/#htc-linux arif-ali (~arif-ali@81.144.163.60) |
| 11:16.13 | *** join/#htc-linux helicopter88 (~helicopte@host66-118-dynamic.55-79-r.retail.telecomitalia.it) |
| 11:25.49 | *** join/#htc-linux stroughtonsmith (~steven@86-42-153-83-dynamic.b-ras1.bbh.dublin.eircom.net) |
| 13:14.31 | *** join/#htc-linux paulk-desktop (~paulk@lib33-1-82-233-88-171.fbx.proxad.net) |
| 13:20.09 | *** join/#htc-linux stroughtonsmith (~steven@ip182.67-202-78.static.steadfastdns.net) |
| 13:26.21 | *** join/#htc-linux stroughtonsmith_ (~steven@86-42-153-83-dynamic.b-ras1.bbh.dublin.eircom.net) |
| 13:56.31 | *** join/#htc-linux Cotulla (~myfakemai@109.205.253.11) |
| 13:57.47 | *** join/#htc-linux DuperMan (Duper@46-116-177-82.bb.netvision.net.il) |
| 14:23.16 | detule | does anyone know how gemini and mercury function on msm |
| 14:24.45 | detule | are they just exposed devices that are ioctl-ed with buffers when jpeg encoding/decoding is needed |
| 14:25.29 | detule | or do they do some magic also with the VFE without necessarily being called by userland directly |
| 14:25.46 | arrrghhh | <PROTECTED> |
| 14:26.29 | detule | need to find me some docs |
| 14:27.42 | Cotulla | which exactly MSM? |
| 14:29.01 | detule | 8960 |
| 14:31.54 | Cotulla | there is also some video processor |
| 14:31.57 | Cotulla | afaik |
| 14:33.53 | detule | from what i can tell there's a front end (vfe) there's a pre-processor (vpe) and perhaps a jpeg engine (gemini/mercury) on top of that |
| 14:34.18 | detule | trying to figure out if that jpeg engine is part of whatever the hell the other two three-letter abbreviations are |
| 14:34.26 | detule | or something separate |
| 14:51.48 | *** join/#htc-linux bartman (~bart@2607:f2c0:f00e:700::dd) |
| 14:53.20 | Cotulla | looks like separate |
| 14:54.05 | Cotulla | what kind of purpose u are looking? |
| 15:00.16 | detule | trying to get the camera working .... |
| 15:01.10 | detule | it's powering up the sensor -> starts queuing/dequeuing buffers from userland....preview works for about one second and then i start getting error interrupts from VFE and everything locks up |
| 15:02.04 | detule | during that one (fraction of a second) if I quickly press the shutter button it even snaps/saves a photo properly |
| 15:03.03 | Cotulla | which error? |
| 15:03.06 | detule | trying to figure out which components are being used during which operation (preview/snapshot/video record) |
| 15:03.13 | Cotulla | I think JPEG module is not problem here |
| 15:03.22 | Cotulla | it's not used during preview I think |
| 15:03.29 | Cotulla | it should be raw YUV stream |
| 15:03.46 | Cotulla | which error do u get? |
| 15:03.56 | Cotulla | maybe it's kinda overflow or wrong timings |
| 15:03.58 | detule | vfe32_irq: axi error |
| 15:04.41 | detule | from media/video/vfe32 |
| 15:04.54 | *** join/#htc-linux ElFinLazz (~elfinlazz@182.215.84.22) |
| 15:06.37 | detule | yeah the overflow/timing could very well be the case |
| 15:09.00 | Cotulla | hm |
| 15:09.09 | Cotulla | is this error come from kernel mode driver? |
| 15:10.56 | detule | sorry don't understand....it's in the media layer.....when camera starts up, vfe is enabled and there's an interrupt listener that waits for signals "done processing frame" from VFE....it works fine for a few frames and then VFE starts sending errors |
| 15:12.14 | Cotulla | I mean "vfe32_irq: axi error" is it kernel mode error? |
| 15:14.28 | detule | http://pastebin.com/8hLvapn2 <--- it has all sorts of debugging enabled a bit hard to read |
| 15:17.08 | Cotulla | vb2: Incorrect planes array length, expected 2, got 0 |
| 15:17.11 | Cotulla | is it important? |
| 15:17.18 | detule | no, it happens on stock as well |
| 15:20.40 | noobhands | wednesday is band practice |
| 15:21.32 | detule | https://github.com/detule/linux-msm-d2/blob/jb_2.5-camera-wip/drivers/media/video/msm_zsl/msm_vfe32.c#L3548 <- the interrupt listener |
| 15:21.37 | noobhands | what day is it Cotulla |
| 15:27.05 | Cotulla | but I think |
| 15:27.10 | Cotulla | axi error is memory access error |
| 15:27.13 | Cotulla | u should check bufers |
| 15:27.13 | *** join/#htc-linux bartman (~bart@2607:f2c0:f00e:700::dd) |
| 15:36.47 | *** join/#htc-linux arif-ali (~arif-ali@94-192-24-56.zone6.bethere.co.uk) |
| 15:43.38 | *** join/#htc-linux stroughtonsmith (~steven@86-42-129-30-dynamic.b-ras1.bbh.dublin.eircom.net) |
| 16:05.45 | *** join/#htc-linux DuperMan (Duper@85-250-109-40.bb.netvision.net.il) |
| 16:43.39 | jonpry | detule, i ordered the nexus4 |
| 16:45.13 | detule | jonpry, nice, can't find a better deal for an unlocked phone than that |
| 16:46.27 | jonpry | no sure can't |
| 16:46.54 | jonpry | and now it's a federal crime to unlock |
| 16:50.03 | detule | so you get that, we rip out mach-msm from CAF, and get working on a 3.8 kernel for s3 and n4 |
| 16:51.09 | jonpry | sounds good to me :) |
| 16:53.49 | jonpry | your 3.4 is all CAF or just mach-msm? |
| 16:58.09 | detule | all caf |
| 16:58.31 | detule | though at this point i have a pretty good idea of the caf additions outside of mach-msm |
| 16:58.41 | jonpry | not even mach-msm from stock? |
| 16:59.06 | detule | a few of my board files are from stock |
| 16:59.13 | jonpry | thats bold |
| 16:59.38 | jonpry | qdsp? |
| 16:59.53 | detule | all caf |
| 17:03.02 | jonpry | you know about all those include related problems with camera? |
| 17:03.43 | detule | i know of some - that wip branch is a few commits behind my local branch |
| 17:04.05 | detule | in particular i stopped trying to be all surgical and shit, and now i am running with the camera headers from stock |
| 17:04.13 | jonpry | like the blobs are compiled using structs in the kernel source |
| 17:04.28 | jonpry | yeah like that |
| 17:04.29 | detule | right so i have this logic in there that translates from old structs to new structs |
| 17:04.51 | detule | some of the headers I couldn't change (the generic v4l2 structs that are not in msm headers) |
| 17:07.21 | detule | like v4l2_event because the v4l layer references members from this new struct |
| 17:08.25 | jonpry | i don't think userland should be sensitive to v4l2 changes |
| 17:08.49 | jonpry | seems like that would be breaking the ABI |
| 17:08.56 | jonpry | and linus would blow off the top |
| 17:10.06 | detule | the ioctl numbers are sensative to v4l2 changes (sizeof v4l2_event is part of the ioc_nr) |
| 17:11.05 | jonpry | this is msm ioctl? |
| 17:14.04 | detule | https://github.com/detule/linux-msm-d2/blob/msm-jb_2.5/drivers/media/video/v4l2-ioctl.c#L2206 |
| 17:15.08 | detule | and others |
| 17:18.53 | jonpry | brb |
| 17:48.48 | jonpry | and sizeof v4l2_event actually changes? |
| 17:50.48 | jonpry | i'm looking at like 3.0 vs 3.7 |
| 17:51.01 | jonpry | and they are the same size |
| 17:51.12 | jonpry | big difference is that reserved[0] became id |
| 17:52.56 | detule | the fact that the union is different doesn't matter? |
| 17:53.18 | jonpry | it's doesn't change the size |
| 17:53.30 | jonpry | and like they only added stuff to the union |
| 17:54.06 | jonpry | presumably the blob won't be queuing up union types it doesn't know about |
| 17:54.24 | detule | ho-hum....i thought the fact that the union is larger would change the size |
| 17:54.45 | jonpry | no that is the thing with union |
| 17:55.00 | jonpry | it's like, this data region of the struct is your choice of: |
| 17:55.45 | detule | cool, that should make my life easier, i can get rid of all this translations between events and new events, i still need to init the id for each event passed from userspace to 0 but that's easy |
| 17:58.07 | detule | no the blob only cares about the data field in the union from what I can tell |
| 17:58.50 | Cotulla | I like how they did that again and again |
| 17:59.01 | Cotulla | chaning structures without backward compatiblle |
| 17:59.56 | jonpry | i think v4l2_event is backward compatible if it was memset(0) |
| 18:01.06 | Cotulla | so where is problem in that case? |
| 18:01.25 | Cotulla | reserved[0] -> id should be good idea |
| 18:01.27 | jonpry | somewhere else |
| 18:01.53 | Cotulla | linux way :) |
| 18:02.07 | detule | in 3.4 they've added an id field to both the event and the subscription and they are matching each event->id against subscription->id |
| 18:02.39 | jonpry | is the blob making garbage in reserved[0] ? |
| 18:03.05 | detule | i don't actually know, but it wasn't matching the events and subscriptions properly before i manually set the id's to 0 for both |
| 18:03.15 | jonpry | sounds like garbage |
| 18:03.20 | *** join/#htc-linux bartman (~bart@2607:f2c0:f00e:700::dd) |
| 18:06.42 | detule | so jonpry when the blob gets the event back |
| 18:06.56 | detule | and tries to access ev.u.data it won't have a problem? |
| 18:07.05 | detule | i don't get this size of union doesn't matter |
| 18:07.21 | jonpry | the size of the union is 64 bytes |
| 18:07.34 | jonpry | it's like the size of the largest member |
| 18:08.03 | jonpry | union is like messed up way of casting |
| 18:08.16 | detule | oh "In a union, at most one of the data members can be active at any time, that is, the value of at most one of the data members can be stored in a union at any time. " |
| 18:08.35 | detule | that IS messed up |
| 18:08.48 | jonpry | tells the compiler to automatically cast that data member or whatever to *(type*)union |
| 18:08.53 | Cotulla | yea |
| 18:09.03 | Cotulla | funny thing in C++ |
| 18:09.07 | Cotulla | *C/C++ |
| 18:09.34 | Cotulla | windows way - u specify API version and it just ignores additional fields :) |
| 18:09.53 | Marc | Cotulla: stop talking about crappy C++ and fix Leo's NAND in 3.0.16 :P |
| 18:10.00 | *** join/#htc-linux kiozen (~kiozen@ppp-93-104-87-192.dynamic.mnet-online.de) |
| 18:10.11 | Marc | I'm busy with yet another stupid test ... |
| 18:11.29 | Cotulla | where u stopped? |
| 18:12.08 | Marc | dmov returning an error code |
| 18:12.44 | Marc | I looked at it a little bit yesterday but I can't figure out what's wrong O.o |
| 18:16.24 | Cotulla | heh |
| 18:16.27 | Cotulla | should be again |
| 18:16.33 | Cotulla | crazy linux developers |
| 18:25.16 | jonpry | detule, it's possible that v4l creates some events and sends them to the blob which it doesn't understand |
| 18:27.43 | detule | from what I can see events are created by the msm part within the media layer so we should be ok with that....buffers are transferred via the general v4l layer and those structs haven't changed at all |
| 18:29.10 | jonpry | how long does it work exactly? |
| 18:29.38 | detule | for a fraction of asecond, you can see how many buffers get exchanged in that log maybe a dozen |
| 18:30.09 | jonpry | maybe it can't free them |
| 18:30.14 | jonpry | dequeue or whatever |
| 18:30.44 | Cotulla | is it using v4l nowdays? |
| 18:30.47 | detule | [ 126.051396] msm_ioctl_server: trouble recognizing ioctl, break |
| 18:30.47 | detule | [ 126.051426] msm_ioctl_server: cmd 89 |
| 18:30.47 | detule | [ 126.051426] msm_ioctl_server: trouble recognizing ioctl, break |
| 18:30.47 | detule | [ 126.051457] msm_ioctl_server: cmd 89 |
| 18:30.47 | detule | [ 126.051457] msm_ioctl_server: trouble recognizing ioctl, break |
| 18:30.48 | detule | [ 126.051487] msm_ioctl_server: cmd 89 |
| 18:30.50 | detule | [ 126.051487] msm_ioctl_server: trouble recognizing ioctl, break |
| 18:30.57 | detule | <--- after i change back to v4l2_event |
| 18:31.02 | detule | it definitely can't recognize the size |
| 18:31.22 | jonpry | run sizeof |
| 18:32.51 | detule | Cotulla, this msm media layer is a complete bastardization of v4l.... |
| 18:34.29 | detule | jonpry, sizeof what v4l2_event? here's the ioctl that fails btw https://github.com/detule/linux-msm-d2/blob/msm-jb_2.5/drivers/media/video/msm_zsl/msm.c#L1785 |
| 18:34.47 | detule | 89 is dqevent |
| 18:36.05 | Cotulla | but why they started to use v4l? before it was totally different |
| 18:36.37 | jonpry | some code like void *foo = sizeof(v4l2_eventold) - sizeof(v4l2-eventnew) |
| 18:36.47 | jonpry | should refuse to compile if they are different |
| 18:37.07 | detule | looks like they tried to upstream it http://www.mail-archive.com/linux-media@vger.kernel.org/msg26091.html <---and got completely shut down |
| 18:38.08 | jonpry | apq8060 had both v4l and msm_cam |
| 18:38.46 | Cotulla | what is used? |
| 18:39.05 | jonpry | webos used v4l |
| 18:39.20 | jonpry | i sort of got it to work with msm_cam on android but it was buggy |
| 18:39.23 | Cotulla | oh |
| 18:39.33 | jonpry | so i used v4l |
| 18:39.38 | detule | they have a v4l device /dev/videox but that's just for queuing and dequeuing buffers...all the business is in /dev/msm_camera/* which also uses SOME of v4l APIs |
| 18:40.07 | detule | the business = configuring the vfe, vpe, postprocessing etc |
| 18:40.11 | Cotulla | but is it mantadory to support all apis? |
| 18:41.35 | detule | jonpry, that void *foo = sizeof(v4l2_event) - sizeof(msm_v4l2_event) only gave me a warning: initialization makes pointer from integer without cast |
| 18:42.09 | Cotulla | lol |
| 18:42.11 | Cotulla | do it as |
| 18:42.21 | jonpry | well thats not good |
| 18:42.29 | jonpry | if it were 0 there would be no warning |
| 18:42.30 | Cotulla | printk("size 1 %d 2 %d\n", sizeof(v4l2_event), sizeof(msm_v4l2_event)); |
| 18:42.38 | jonpry | but then you have to run it :p |
| 18:42.45 | detule | yeah trying to avoid that :) |
| 18:43.06 | jonpry | isn't there some gcc macro for printing constants to the log? |
| 18:45.11 | Cotulla | so just compile |
| 18:45.11 | ali1234 | #pragma warning <whatever> |
| 18:45.15 | Cotulla | and disassemble |
| 18:45.28 | Cotulla | and see numbers near with prink |
| 18:45.30 | Cotulla | printk |
| 18:45.48 | jonpry | objdump foo.o ? |
| 18:46.01 | detule | screw it compile and kexec |
| 18:46.20 | jonpry | in that case |
| 18:46.26 | jonpry | i think there is more info required |
| 18:46.46 | jonpry | imho the trouble has to be that one of the structs in the union is larger than 64 bytes |
| 18:49.57 | jonpry | so maybe sizeof v42l2_event.u as well |
| 18:50.35 | *** join/#htc-linux arif-ali (~arif-ali@94-192-24-56.zone6.bethere.co.uk) |
| 18:50.57 | Cotulla | yeah funny story in maillist |
| 18:52.04 | detule | jonpry, so on the touchpad you only used /dev/videoX? |
| 18:52.10 | detule | which userland HAL did you use for that |
| 18:52.43 | detule | i have a generic v4l2 driver for my camera sensor from elsewhere that i've been thinking about trying to use, but not sure which HAL I would use for that.....it would all be raw jpeg but i guess better than nothing |
| 18:54.03 | detule | 08-12 21:19:14.456 INFO : STUPIDITY: sizeof(v4l2_event)=80, sizeof(msm_v4l2_event)=78 |
| 18:54.04 | detule | 08-12 21:19:14.457 INFO : STUPIDITY: sizeof(v4l2_event.u)=40, sizeof(msm_v4l2_event.u)=40 |
| 18:54.13 | detule | that's %x |
| 18:55.05 | jonpry | maybe i need to see your msm_v4l2_event |
| 18:55.37 | detule | https://github.com/detule/linux-msm-d2/blob/jb_2.5-camera-wip/include/linux/videodev2.h#L2401 |
| 18:56.21 | Cotulla | lol STUPIDITY |
| 18:56.27 | Cotulla | debug comment of the week |
| 18:56.27 | Cotulla | :D |
| 18:56.37 | detule | needed something easy to grep :) |
| 18:58.46 | detule | btw now that I am looking at the structs that printout makes no sense |
| 18:59.42 | jonpry | yeah for real |
| 19:00.18 | jonpry | it must be a packing problem |
| 19:00.25 | jonpry | like timespec is all 64bit |
| 19:01.09 | detule | as is this vsync |
| 19:01.22 | detule | i mean __attribute(packed) |
| 19:01.47 | detule | oh but that's in both nvm |
| 19:02.20 | Cotulla | use offsetof() to check |
| 19:03.05 | jonpry | i count 0x80 for both |
| 19:03.16 | jonpry | so how can the one be 0x78? |
| 19:03.54 | jonpry | 4+64+4+4+16+9*4 |
| 19:04.19 | jonpry | er |
| 19:04.29 | jonpry | long is 32bit? |
| 19:06.39 | jonpry | in which case it is 0x78 |
| 19:08.20 | detule | so wtf, try a different toolchain? |
| 19:09.02 | jonpry | i think cotulla was right with offsetof |
| 19:09.06 | jonpry | to see what it has done |
| 19:09.20 | jonpry | there might be like a #pragma pack going on |
| 19:09.42 | jonpry | or maybe one of the new unions starts with a 64bit member |
| 19:10.31 | jonpry | <PROTECTED> |
| 19:13.07 | Cotulla | another way |
| 19:13.12 | Cotulla | generate DWARF information |
| 19:13.15 | Cotulla | and dump it to look offsets |
| 19:13.42 | jonpry | well check this out |
| 19:13.45 | jonpry | struct v4l2_event_ctrl |
| 19:13.53 | jonpry | is one of the unions |
| 19:14.22 | jonpry | bleh never mind 36 bytes |
| 19:23.38 | Cotulla | why not just use offsetoff() to check critical offsets? |
| 19:23.46 | Cotulla | as well good way to play "gold rule" game |
| 19:23.49 | Cotulla | :D |
| 19:27.32 | detule | [oliver@localhost linux-msm]$ adb shell dmesg | grep STUPID |
| 19:27.32 | detule | 08-12 21:52:55.423 INFO : STUPIDITY: sizeof(v4l2_event)=80, sizeof(msm_v4l2_event)=78 |
| 19:27.32 | detule | 08-12 21:52:55.430 INFO : STUPIDITY: sizeof(v4l2_event.u)=40, sizeof(msm_v4l2_event.u)=40 |
| 19:27.32 | detule | 08-12 21:52:55.437 INFO : STUPIDITY: sizeof(v4l2_event.type)=4, sizeof(msm_v4l2_event.type)=4 |
| 19:27.32 | detule | 08-12 21:52:55.444 INFO : STUPIDITY: sizeof(v4l2_event.timespec)=8, sizeof(msm_v4l2_event.timespec)=8 |
| 19:27.33 | detule | 08-12 21:52:55.452 INFO : STUPIDITY: sizeof(v4l2_event.sequence)=4, sizeof(msm_v4l2_event.sequence)=4 |
| 19:27.34 | detule | 08-12 21:52:55.460 INFO : STUPIDITY: sizeof(v4l2_event.pending)=4, sizeof(msm_v4l2_event.pending)=4 |
| 19:27.36 | detule | 08-12 21:52:55.468 INFO : STUPIDITY: sizeof(v4l2_event.reserved)=20, sizeof(msm_v4l2_event.reserved)=24 |
| 19:27.38 | detule | 08-12 21:52:55.476 INFO : STUPIDITY: msm: offsets: type=0; u=4; pending=44; sequence=48; timestamp=4c; reserved=54 |
| 19:27.41 | detule | 08-12 21:52:55.485 INFO : STUPIDITY: non-msm: offsets: type=0; u=8; pending=48; sequence=4c; timestamp=50; id=58; reserved=5c |
| 19:29.43 | jonpry | yeah it's like aligning the union on 8 bytes |
| 19:34.28 | jonpry | detule, your always breaking the compiler |
| 19:35.03 | detule | err this is with the one that we always used in xdandroid 2010.09 |
| 19:35.22 | jonpry | maybe need something older |
| 19:35.40 | detule | can i force that alignment on 4 bytes somehow |
| 19:35.54 | jonpry | you can try __attribute__ ((packed)) |
| 19:37.51 | jonpry | hmm |
| 19:37.58 | jonpry | i think i understand why it is doing this |
| 19:38.33 | jonpry | it's v4l2_ctrl.value64 |
| 19:38.58 | jonpry | thats awesome this is like a real kernel bug :p |
| 19:39.19 | jonpry | and a one liner at that |
| 19:41.35 | detule | packing v4l2_event did the trick |
| 19:42.52 | jonpry | gonna submit a patch? |
| 19:43.17 | detule | i am not even sure this is in korg kernels |
| 19:43.24 | detule | but no, you got this |
| 19:43.50 | jonpry | it totally is |
| 19:43.54 | jonpry | it's in 3.7 |
| 19:43.59 | detule | great now i am back to square one - camera still fails after a fraction of a second |
| 20:00.14 | detule | i know you are syncing linux stable right now |
| 20:02.46 | *** join/#htc-linux arif-ali (~arif-ali@94-192-24-56.zone6.bethere.co.uk) |
| 20:03.46 | jonpry | i wish |
| 20:03.55 | jonpry | nobody is going to like this patch |
| 20:04.28 | jonpry | i found it http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=6e239399e5807132f86f64af6c659411c6a3d1a5 |
| 20:04.45 | *** join/#htc-linux Ondalf (~ondalf@cable-roi-50ddf8-39.dhcp.inet.fi) |
| 20:05.13 | jonpry | so old that restoring the ABI is going to sound a lot like breaking it again |
| 20:05.38 | detule | how did that now break a lot of blobs when it was introduced |
| 20:05.56 | jonpry | who uses v4l? |
| 20:06.42 | jonpry | and even if they could be convinced to restore the ABI |
| 20:06.57 | jonpry | this attribute pack thing causes unaligned load/store on 64bit |
| 20:12.56 | jonpry | iirc there was some build option in cyanogenmod that turned on v4l |
| 20:13.06 | jonpry | omap used it or something |
| 20:16.14 | jonpry | i don't even know what a HAL is |
| 20:16.38 | fakker | i do |
| 20:16.38 | fakker | :O |
| 20:17.06 | detule | i mean which libcamera on the android side |
| 20:17.37 | fakker | dolan duck says hi |
| 20:17.41 | fakker | hgh guyz |
| 20:48.20 | *** join/#htc-linux jonpry (~jon@2602:306:c417:8aa0:15e5:46e7:9465:ac40) |
| 21:03.48 | *** join/#htc-linux arif-ali (~arif-ali@94-192-24-56.zone6.bethere.co.uk) |
| 21:33.36 | jonpry | detule, so i have been told that the new ABI is the ABI |
| 21:36.11 | *** join/#htc-linux Cotulla (~myfakemai@109.205.253.11) |
| 22:04.03 | *** join/#htc-linux BabelO (~fcr@unaffiliated/babelo) |
| 22:09.02 | *** join/#htc-linux Echo31 (~olivier@lan31-9-88-177-158-48.fbx.proxad.net) |
| 22:55.53 | *** join/#htc-linux bartman (~bart@2607:f2c0:f00e:700::dd) |