ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | Wiki at http://linux-rockchip.info | Logs at http://irclog.whitequark.org/linux-rockchip | ML at http://groups.google.com/group/linux-rockchip
cristian_c has quit [Quit: Bye]
nighty^ has quit [Quit: Disappears in a puff of smoke]
nighty^ has joined #linux-rockchip
nighty-_ has joined #linux-rockchip
nighty^ has quit [Ping timeout: 260 seconds]
Ueno_Otoko has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
naobsd has joined #linux-rockchip
robogoat has quit [Ping timeout: 245 seconds]
robogoat has joined #linux-rockchip
Ueno_Otoko has quit [Ping timeout: 260 seconds]
Ueno_Otoko has joined #linux-rockchip
markm has quit [Ping timeout: 245 seconds]
naobsd has quit [Ping timeout: 260 seconds]
naobsd has joined #linux-rockchip
ssvb has quit [Ping timeout: 250 seconds]
premoboss has quit [Quit: Sto andando via]
AstralixNB has joined #linux-rockchip
ssvb has joined #linux-rockchip
naobsd has quit [Quit: naobsd]
markm has joined #linux-rockchip
Ueno_Otoko has quit [Ping timeout: 260 seconds]
Ueno_Otoko has joined #linux-rockchip
c0d3z3r0 has quit [Ping timeout: 245 seconds]
c0d3z3r0 has joined #linux-rockchip
wadim_ has joined #linux-rockchip
naobsd has joined #linux-rockchip
nighty-_ has quit [Ping timeout: 260 seconds]
nighty-_ has joined #linux-rockchip
ssvb has quit [Ping timeout: 250 seconds]
mrueg has quit [Remote host closed the connection]
mrueg has joined #linux-rockchip
wadim_ has quit [Remote host closed the connection]
markm_ has joined #linux-rockchip
markm has quit [Ping timeout: 245 seconds]
ssvb has joined #linux-rockchip
nighty-_ has quit [Ping timeout: 250 seconds]
nighty-_ has joined #linux-rockchip
cnxsoft has quit [Quit: cnxsoft]
Ueno_Otoko has quit [Ping timeout: 250 seconds]
nighty-_ has quit [Quit: Disappears in a puff of smoke]
AstralixNB has quit [Quit: Leaving.]
gb_master has joined #linux-rockchip
jas-hacks has joined #linux-rockchip
GriefNorth has joined #linux-rockchip
jas-hacks has left #linux-rockchip [#linux-rockchip]
<amstan> mmind00_: @collabra.com? what's going on there? heh
<mmind00_> amstan: :-)
gb_master has quit [Quit: Leaving]
ssvb has quit [Ping timeout: 260 seconds]
<pulser> :)
ckeepax has joined #linux-rockchip
<pulser> mmind00_: random question - is there some component of the armsoc driver present in the kernel tree (I assume there must be, even if not technically part of armsoc)?
<mmind00_> somewhat-stable currently carries an additional ioctl for creating gems from the armsoc xserver (but that is temporary and that ioctl should probably go away)
<pulser> I ask, as I wanted to do a quick check over the graphics stack (higher up the chain than the dp) to see if there were any obvious differences that might break accel
<pulser> hmm OK - that shouldn't affect it
<mmind00_> just FYI: armsoc-rockchip could also do it like: http://lists.x.org/archives/xorg-devel/2015-May/046352.html
<mmind00_> but there is a rant from the DRM-maintainer "available" where he strongly claims that the dumb ioctls should not be used for this
<pulser> interesting
<pulser> I suppose you could argue it's a bit of overkill
<mmind00_> if you look in the rockchip drm, both the dumb_ioctl as well as the "new" one do the same, so yes :-)
<mmind00_> but that is I fight I haven't dared to take yet ;-)
<pulser> heh - tbh it's a bit over my head, as I am not used to this intermediate level of abstraction
<pulser> but yeah, I can understand someone saying "this is not what an ioctl is designed for"
<mmind00_> yeah, but introducing another one that does the same is equally strange :-)
<pulser> indeed!
<pulser> hmmm
<pulser> so if I understand this right, ARM graphics are just a general mess, because of the lack of a "standard" stack?
<pulser> and therefore we have 3D accel totally uncoupled from 2D accel, and so on and so forth
<pulser> interesting - this came up in a bit of searching on the topic - https://github.com/torvalds/linux/commit/355a70183848f21198e9f6296bd646df3478a26d
<mmind00_> pulser: not a mess, just different ... on most ARMs the gpu is a separate component, detached from the actual display pipeline and renders simply into a block of memory
<pulser> ah right, so I assume "shared memory" (hence the ashmem drivers on android etc?), and the "GPU" writes the frame to render into that block of RAM?
<pulser> and from there, the display driver "pulls" from that RAM, and punts it onto the screen?
<mmind00_> I'm also definitly no expert on the display side, but I guess something like that
<pulser> me neither, but I think it makes sense to me to be done like that
<pulser> certainly it's now I have seen some embedded systems work
<pulser> well I found the issue on acceleration on X on your somewhat-stable tree - X showing errors of :
<pulser> DRI2SwapBuffers: driver failed to schedule swap
<pulser> flip queue failed: Invalid argument
<pulser> (repeated over and over)
<pulser> es2gears is fine, but it's not enough to get compiz or similar running - I assume something for buffer swapping isn't working yet or implemented
ssvb has joined #linux-rockchip
GriefNorth has quit [Ping timeout: 260 seconds]
rory096 is now known as wumbotarian
AstralixNB has joined #linux-rockchip
wumbotarian is now known as rory096
vickycq has quit [Ping timeout: 245 seconds]
ckeepax has quit [Ping timeout: 260 seconds]
ckeepax has joined #linux-rockchip
ckeepax has quit [Ping timeout: 245 seconds]
cristian_c has joined #linux-rockchip
nighty^ has joined #linux-rockchip
cristian_c has quit [Read error: Connection reset by peer]
AstralixNB has quit [Quit: Leaving.]