10:34 <ndufresne> javier__: cool, I've mapped the tiled format into the kernel, right now it renders the Y plane correct, but we have no colors (likeif UV planes is completly ignored)

10:34 <ndufresne> javier__: if we use PRIME of the dmabuf fd, the driver crash

10:35 <ndufresne> at the biginning our stride was wrong, but fixing that didn't remove the crash (that crash should never happen, it's unpreviledge process passing that data, we should have checks to prevent this)

10:36 <ndufresne> javier__: may you can pass that to whoever maintain the DRM driver ? https://paste.fedoraproject.org/366299/22188146/

10:37 <ndufresne> hmm, actually, it my be on v4l2 side here

11:57 <ndufresne> javier__: got a bidbuck bunny 1080p video that does not play till the end, it fails on error 0x7c INCOMPLETE_FRAME

11:58 <ndufresne> I'm sure we can and should recover from this

11:58 <ndufresne> we should also add a debug swich that prints the name of the errors, would make our lives much easier, cause not everyone have access to the spec

14:08 <pokazef> javier__: I compiled mainline 4.4.8 for my odroid-u3 but still no luck with the fan...

14:56 <Putti> Hi, I have Samsung galaxy s3 lte (soc exynos 4412). Do you know what I should enable in kernel in order to show the kernel debug messages during boot? Should the kernel parameter console be tty0 (or does it even matter)? I tried different things under Device Driver -> Graphics Support but with no luck.

14:57 <Putti> forgot to mention that I want the debug messages to show on the device's lcd.

15:14 <LiquidAcid> Putti, that probably depends on the bootloader

15:14 <Putti> LiquidAcid, why so?

15:15 <Putti> LiquidAcid, I can change the splash screen during kernel load, so I think it would be possible to have the messages printed, too.

15:17 <LiquidAcid> Putti, because the bootloader has to setup e.g. fimd to scanout from a framebuffer, the kernel initializes DRM pretty late in the process

15:20 <Putti> Hmm, I think I didn't understand anything from you message, I'm pretty new to arm devices and kernel hacking :/ But there is "LCD init in kernel" option in the kernel, does that change anything?

15:21 <LiquidAcid> Putti, like i said, you don't want to rely on the kernel setting up your display, that's going to too late to see any important messages

15:21 <LiquidAcid> if you know how the bootloader setups fimd, you could maybe use simplefb

15:21 <LiquidAcid> (i assume here that the lcd is connected via fimd)

15:22 <Putti> LiquidAcid, I need to check that (and first what is fimd...)

15:25 <Putti> LiquidAcid, what did you mean by initializing DRM? Do LCD controller chips have some sort of DRM restrictions? O.o

15:26 <Putti> oh, I guess it's dynamic random-access memory...

15:26 <Putti> :D

15:26 <Putti> or is it?

15:26 <LiquidAcid> Putti, no, DRM is the main linux graphics subsystem

15:27 <Putti> okay, thank you ! :)

15:32 <Putti> Hmm, is it possible to have kernel debug messages outputted via usb cable?

15:43 <wwilly> hi

15:43 <wwilly> Putti, maybe with an UARTtoUSB or something like that

15:44 <Putti> wwilly, okay. What do I need to enable in kernel?

15:45 <Putti> console=USB0 ?

15:47 <wwilly> I'm out of context of your discussion, which board, which linux distro?

15:48 <Putti> Samsung galaxy s3 lte (soc exynos 4412), no distro

15:48 <Putti> i'm trying to get just some output so that I can see what went wrong when it tries to launch /init in initramfs

15:49 <wwilly> with a debug console, you could have the trace from the bootloader and linux, and have a tty either

15:50 <ndufresne> Any one knows how the DRM pixel format modifiers are suppose to be used by userspace ?

15:50 <LiquidAcid> ndufresne, you use them for addfb2

15:50 <Putti> wwilly, yup and at the moment I don't have any console :/

15:50 <ndufresne> but the mod is 64bit isn't it ? and flags is 32bit (if that's the right param

15:51 <wwilly> Putti, but I don't know if you have a debug port available on this smartphone, probably not, as it is not intended to nerdy stuff

15:51 <LiquidAcid> ndufresne, https://cgit.freedesktop.org/mesa/drm/tree/include/drm/drm_mode.h#n399

15:51 <LiquidAcid> ndufresne, all modifiers are uint64_t

15:52 <LiquidAcid> ndufresne, you can have to call the ioctl directly, currently there is no wrapper call in libdrm

15:52 <LiquidAcid> in case that's what you're asking

15:52 <ndufresne> ah, yes, the code I'm using is using libdrm

15:53 <ndufresne> but I've just lookup the drmModeAddFB2(), it's really just an IOCTL wrapper

15:53 <LiquidAcid> ndufresne, then you probably have to roll your own addfb2ext call

15:53 <LiquidAcid> ndufresne, almost all calls in libdrm are ioctl wrappers

15:53 <ndufresne> LiquidAcid: I just went the wrong route today to enable NV12 tile format for Exynos 4412 VideoProcessor

15:53 <ndufresne> and trying to cleanup now

15:54 <LiquidAcid> ndufresne, yeah, i had a patch for that in my local tree, but i never tested it

15:54 <ndufresne> LiquidAcid: also, apparently we don't do any check in the driver when trying to map the dmabufs, so if someone pass an invalid offset, it just crash

15:54 <wwilly> Putti, a yes it exist some stuff, specially for cracking cell phones, http://www.cellcorner.com/xshp/unlock-phone-codes/samsung-s5550-j808-s5253-b7722-b3410w-microuart-usb-unlock-cable-z3x.html

15:55 <ndufresne> Anyway, I'll finish getting that format to work, and then I'll retry the dmabuf path

15:55 <LiquidAcid> ndufresne, yeah, the driver quality isn't all that good, don't get me started on g2d

15:56 <ndufresne> haha

15:56 <Putti> wwilly, but I have no idea which bit to enable in the kernel config in order to get any output from that.

15:56 <ndufresne> LiquidAcid: if I use g2d, it will most likely be using the v4l2 driver instead (which isn't great either to be honnest)

15:56 <wwilly> Putti, me neither, can't help at this point

15:57 <LiquidAcid> ndufresne, never used that one, i only looked at the code for reference

15:57 <LiquidAcid> ndufresne, only plus is that it also works for the older fimg2d hw revision

15:57 <ndufresne> for my case it's just that v4l2 is better suited for streaming

15:58 <ndufresne> and it implement both dmabuf roles

15:58 <Putti> wwilly, yeah, I will try to look on the internet if anyone else has done something like this. And thanks for the help! :)

15:58 <ndufresne> LiquidAcid: thanks btw, if you are interested, I'll keep you posted

15:59 <LiquidAcid> ndufresne, i assume you're also working on mfc then?

15:59 <ndufresne> LiquidAcid: I'm trying to get GStreamer to work with the v4l2 codec combined with kms directly, so we can start testing codec before wayland/x11 or whatever is ready

16:00 <ndufresne> yeah, but mfc seems to work decently with the new memory reservation, and 2 patches from javier__ and ayaka

16:00 <ndufresne> ok, have to go

16:00 <LiquidAcid> ah ok, not really interested in gstreamer

16:01 <ndufresne> LiquidAcid: I mean the patch to finish the tiling support

16:01 <ndufresne> I'll keep you posted for that

16:01 <LiquidAcid> yeah, but that's kinda pointless for me if i have nothing to test it with

16:02 <ndufresne> ok, then I'll obay to the maintainer script ;-P

16:02 <LiquidAcid> would be different if libdrm's helper function could produce nv12mt pictures

16:02 <ndufresne> I can add test if that's what you want, it's not hard

16:03 <ndufresne> its also usefull for qcom stuff

16:03 <LiquidAcid> well, i would be looking forward to a mfc backend in ffmpeg

16:03 <LiquidAcid> but it's not really important for me anyway, since i don't use the board to watch movies

16:04 <ndufresne> that I'm not your man, did it for gst, debugged Chromium one, that's enough ;-P

16:04 <LiquidAcid> still good to see someone is working on it

16:05 <LiquidAcid> seamonkey here :)

16:05 <ndufresne> to me this is just a test platform, I care as much for qcom, imx6, then this one

16:05 <ndufresne> ok, leaving for real

16:05 <LiquidAcid> take care

20:27 <pokazef> javier__: After learning about the PWM interface, I got the U3 fan to work (barely) on Tobias' tree.

20:28 <LiquidAcid> pokazef, why barely?

20:28 <pokazef> LiquidAcid: it can be turned on, but not off and doesn't provide any duty-cycle control

20:29 <LiquidAcid> pokazef, i was under the impression that this is fully automatic

20:29 <LiquidAcid> you just enable the proper thermal governor for the fan

20:29 <LiquidAcid> pokazef, see in particular http://rglinuxtech.com/?p=1309

20:29 <pokazef> LiquidAcid: I've been controlling the fan manually through sysfs

20:30 <LiquidAcid> pokazef, well, that's not how you should do it

20:31 <pokazef> LiquidAcid: That's how I've been doing it for years

20:32 <LiquidAcid> pokazef, it's wrong though, userspace should never do thermal management

20:33 <LiquidAcid> and doing it in kernel is already a big compromise

20:34 <pokazef> LiquidAcid: if userspace is not allowed to do fan control, then it's up to meatspace to unplug the fan when it's no longer needed...

20:34 <pokazef> Not an ideal solution either

20:35 <LiquidAcid> pokazef, the thermal cores allows for userspace interaction, what's exactly the problem there?

20:35 <LiquidAcid> *core

20:35 <pokazef> LiquidAcid: I don't know about the thermal core interface, I'm just used to the PWM stuff is all

20:36 <pokazef> I'll have another look at the whole thing tomorrow

20:36 <LiquidAcid> pokazef, again, this is the wrong way to control the fan

20:36 <LiquidAcid> pokazef, just because hardkernel decided to make a userspace daemon for this, doesn't mean the approach is sane at all

20:37 <pokazef> LiquidAcid: OK, thanks for the info