zenmetsu has quit [Ping timeout: 264 seconds]
zenmetsu has joined #linux-exynos
LanDi has joined #linux-exynos
zenmetsu has quit [Ping timeout: 252 seconds]
zenmetsu has joined #linux-exynos
zenmetsu has quit [Ping timeout: 260 seconds]
LanDi has quit [Quit: fui !]
amitk has joined #linux-exynos
jnettlet has quit [Remote host closed the connection]
jnettlet1 has quit [Remote host closed the connection]
jnettlet has joined #linux-exynos
<amitk> sjoerd: Got to trying out your kernel and configuring Xorg but startx fails with the following log: http://paste.ubuntu.com/9438677/ Any clues?
<sjoerd> FPE ? that sounds special
<sjoerd> amitk: i havne't tried X on this yet, so not sure
<amitk> sjoerd: you tried this with wayland? Do you know if the ubuntu wayland packages work?
<amitk> else I'll have to spend time switching to debian
<sjoerd> I'd always recommend switching to debian :p
<sjoerd> But the ubuntu weston package should work
<sjoerd> if you launch it with the pixman rendering backend that is
<amitk> sjoerd: I don't even know what that means (pixman rendering) :)
<sjoerd> amitk: One thing to double-check is if your permissions on /dev/mali etc are correct for the user you're launching X as
<sjoerd> amitk: Oh, that means weston uses software compositing. You can't use EGL/GL on wayland with mali just yet
<sjoerd> amitk: but if weston properly comes up you'll at least know that the display subsystem works correctly
<amitk> sjoerd: so how do I launch weston?
<sjoerd> amitk: log into a VT and run weston-launch -- --use-pixman
<amitk> hey, that seemed to work, though my touchpad isn't responding
<sjoerd> my xu3 wip tree doesn't have the cb2 touchpad patches in
<sjoerd> you can grab those from my wip/exynos-touchpad branch
<amitk> sjoerd: hmm, evtest is showing the button clicks on the touchpad, not the finger movements
<amitk> actually, everything is showing up as BTN_LEFT, will investigate the dts
<sjoerd> amitk: is that with those patches ?
<sjoerd> Ah, so upstream does have the dts snippet
<javier__> sjoerd: yes, only the atmel T100 multi-touch object support in the driver is missing in mainline
<javier__> amitk: have you cherry-picked ced0716 ("Input: atmel_mxt_ts - implement support for T100 touch object") and 5af117e ("WIP - Input: atmel_mxt_ts: potentailly register T100 as a touchpad") from sjoerd's wip/exynos-touchpad branch?
<javier__> amitk: the peach pit and pi have different atmel chips that use different multi-touch protocols, only the one for the pit is supported in the mainline driver right now
<javier__> amitk: iirc that is needed for the multi-touch events but support for the button event is the same which matches the behaviour you described
<javier__> amitk: about everything reported as BTN_LEFT, daniels explained to me that it is because is a touchpad with a single button and user-space use a combination of button pressed and mt positions to figure out a right click was made for example
<daniels> right, the tracking is too complex to figure it out in the kernel
<amitk> javier__: thanks, with those two cherry-picks I get "unaccelerated" cursor movement
<amitk> daniels: sjoerd: so what interesting things can I do in this weston environment? I guess running X apps is not possible...
<daniels> amitk: xwayland is possible in theory but we don't build support for that. (should fix that!)
<daniels> amitk: you can run gtk apps tho
<sjoerd> amitk: you can't use the mali though, but this at least means your display subsystem is up and works
<sjoerd> amitk: can you get a backtrace from your Xorg crash?
<daniels> amitk: if you get the chromeos mali binaries (assuming they're released for the 5422 rather than just 5250) then you can run X11/mutter/chrome/etc
<sjoerd> daniels: his X crashed on startup, which is why he tried weston :)
<amitk> sjoerd: I'll try to setup all the -debug packages and capture a backtrace from Xorg
<javier__> amitk: great, I should find some time to clean those atmel patches and post them upstream
<amitk> javier__: feel free to cc me and I'd be happy to give my "Tested-by"
<javier__> amitk: thanks
<sjoerd> javier__: my outstanding thing with those is that really the init function should work for both version
<sjoerd> currently it has different ones fro the two protocols which are functionality wise for 90% the same
<javier__> sjoerd: I know, by clean I mean factor out the init sequence for both
<sjoerd> ;)
<javier__> sjoerd: I should also prod to the mmc/sdio wifi support a bit more, just cherry-picking and adapting the DTS snippets is not enough so I've to dig deeper what the downstream changes in the dw_mmc host driver are
<sjoerd> i see
<sjoerd> javier__: does samsungs exynos-reference work ooi ?
<sjoerd> that might have more targetted dw mmc changes then the chromeos kernels
<javier__> afaict those are the only two peripherals that are missing to have full peach pi support (modulo hw acceleration)
<sjoerd> javier__: webcam!
<javier__> right!
<javier__> but that is *just* USB right?
<daniels> heh
<sjoerd> Yeah it just needs to be powered on i think
<javier__> I see
* javier__ adds webcam to his TODO
<amitk> javier__: sjoerd is right, no device support is complete these days until it can be used to take a selfie ;)
<javier__> amitk: lol
<daniels> sjoerd, amitk: yeah, synaptics is hosed I guess
<sjoerd> cheese is a critical user application!
<sjoerd> daniels: oh you suspect that crash is in synaptics?
<sjoerd> amitk: worth trying with a working touchpad if that's the case ^
<amitk> sjoerd: "working touchpad" from where?
<sjoerd> amitk: i thought you mentioned that with those extra patches your touchpad works in weston now?
<amitk> sjoerd: it does
<sjoerd> so worth seeing if that "solved" your X problem
<amitk> ohh
* amitk would never have linked touchpad to X but ok, I'll try it
<sjoerd> amitk: the syntaptic driver is the one that interacts with the touchpad and suspiciously the last log line from X before the crash is from it
<amitk> sjoerd: daniels: thanks! Xorg started!
<sjoerd> \o/
<amitk> now to figure out how to get Mali acceleration
<sjoerd> at this poitn that should be a matter of putting the blobs in the right spots
<javier__> amitk: \o/
<amitk> sjoerd: yes, looks like I have mesa libs installed that I should first get rid of
<amitk> sjoerd: do you know if r4p1 blobs (mali-t62x_r4p1-00rel0_linux_1+fbdev.tar.gz, mali-t62x_r4p1-00rel0_linux_1+x11.tar.gz) will work with your kernel? I just realised I might be using something too shiny...
<sjoerd> i think the kernel space is r4p0 but i always forget
<amitk> sjoerd: I don't see the r4p1 string in the commit logs or code, I do see r4p0, so you might be right
* amitk goes to find older blobs
<sjoerd> amitk: I've always just the blobs from chromeos
<sjoerd> those also have dmabuf import support which is nice
<Wizzup> but does it actually give you accel that you can use, apart from opengles?
<sjoerd> eh
<sjoerd> GLESv2 is accell you can use
<sjoerd> I'm not sure why you want to meaningfully accelerate on arm that can't do gles tbh
<Wizzup> What do you mean, on arm?
<javier__> Wizzup: big GL is not even supported by the mali GPU afaik
<sjoerd> on an ARM based platform
<Wizzup> There are plenty of examples of programs that only do opengl, not gles, including many visualisation toolkits, etc
<Wizzup> javier__: I know :) but proper 2d and video accel is probably more welcome for me
<sjoerd> On x86 there is al ot of legacy which isn't there on arm
<Wizzup> I wouldn't call much of what I use legacy :)
<Wizzup> but, sure
<sjoerd> Not sure which visualisation toolkit you're referring to here
<Wizzup> I mean, I live without accelerated opengl for a long time now and it's mostly not a problem, I just know very little that uses opengles
<sjoerd> i would expect things like opencv to be able to do gles
<Wizzup> maybe mpv can use it for scaling
<Wizzup> sjoerd: vtk,paraview,blender probably too
<Wizzup> Not sure if firefox can use it for webgl; libreoffice doesn't use it afaik
<sjoerd> we've got fully accelerated output paths video playback with gstreamer on these devices
<Wizzup> you've got that to work?
<sjoerd> Wizzup: well that's what we use these things for, so, yeah
<sjoerd> firefox runs on android afaik , so that should be able to do gles
<Wizzup> should doesn't mean it's by any sense enabled on non android, but maybe :)
<sjoerd> so does blender
<Wizzup> that's news for me @ blender
<sjoerd> blender was a GSoC project, not sure if that got merged back in
<sjoerd> but anything that can run on, well, not Mac/PC will support gles
<Wizzup> I don't think that has been my experience
<Wizzup> maybe you can post some pointers on the video accel at some point?
<sjoerd> that's all either upstream or moving upstream
<javier__> sjoerd: I guess the chormium browser should also use gles for video right? so you can do hangout and other stuff
<Wizzup> right, I have gstreamer 1.2.4
<sjoerd> you want 1.4.x
<sjoerd> javier__: Yeah but you need to bang on it to get those bits to build on non-{android/chromeos}
<javier__> sjoerd: I see
<Wizzup> Sounds like my experience with webrtc on arm too
<sjoerd> Wizzup: 1.4.x supprots the hardware video decoder on exynos, hopefully for 1.6.x the whole dmabuf zero-copy path will just work
<Wizzup> I see, well, I'm not planning on using the mali driver at this point, but other stuff is always nice
<Wizzup> After a lot of experimenting I still find xf86-video-fbturbo to give me one of the most pleasant experiences
<sjoerd> javier__: for extra frun the hw video decoding/encoding stuff in chromium doesn't do autodetection
<sjoerd> So to enable it properly on general purpose linux would need some effort
<javier__> sjoerd: oh, I remember you mentioned that before that they kind of hardcode the {en,de}coding path
<sjoerd> yeah
<sjoerd> icluding the device nodes etc
<javier__> :-/
<javier__> sjoerd: but still, thinking about a general purpose linux desktop on an ARM platform was a dream a couple of years ago, so this is progress
<sjoerd> hehe
amitk has quit [Quit: leaving]
afaerber has joined #linux-exynos
HcE has quit [Remote host closed the connection]
afaerber has quit [Quit: Verlassend]
tyler-baker has joined #linux-exynos
afaerber has joined #linux-exynos
LanDi has joined #linux-exynos
RSpliet has joined #linux-exynos
dlezcano has quit [Quit: Leaving]
RSpliet has left #linux-exynos [#linux-exynos]
dlezcano has joined #linux-exynos