17:36 <oillamp> hey all, im booting a mainline kernel (the one packaged by arch linux) on a chromebook snow with nv_u-boot + initramfs + luks encrypted rootfs... the issue is i'm not getting any output from the ramdisk, and no prompt for typing in the passphrase to unlock the rootfs. having some tests, a keyfile-based decryption unlocks the rootfs as expected and takes me to the login, so i guess the uboot images are

17:36 <oillamp> working fine... any idea? thanks.

19:45 <prahal__> Xorg get stuck when I rebase above 4.11, but only when I launch I app from gnome-shell dash :/

19:46 <LiquidAcid> prahal__, gdb?

19:46 <prahal__> kernel it seems , when I revert a bunch of (50) commits all is fine

19:47 <prahal__> I hint it has to do with hw cursor and planes (xorg spends most fo its time there with bad kernel )

19:48 <LiquidAcid> you are using armsoc?

19:48 <prahal__> well my own mix of the armsoc repositories :/

19:49 <LiquidAcid> i guess it's due to armsoc not using atomic yet

19:50 <prahal__> in fact my aim for today was to cleanup those armsoc local fixes to send upstream !

19:50 <prahal__> NotifyFd ?

19:50 <LiquidAcid> so updates of the cursor plane slow things down

19:52 <LiquidAcid> no idea why notifyfd is

19:52 <LiquidAcid> *what

19:52 <LiquidAcid> isn't this some udev thing=

19:52 <LiquidAcid> ?

19:55 <prahal__> xorg/drm related

19:56 <prahal__> required by newest xorg api

20:00 <prahal__> well I cannot tell if my stack handling atomic update properly ... I thought it was transparent to upper layers (well I added the fix from armsoc meson to exynos to fix mouse flickers but not much more)

22:06 <LiquidAcid> prahal__, is it using drmModeSetCrtc and drmModeSetPlane?

22:39 <prahal__> got a better *test case* .... grab a window and move .... the cursor move but not the window , which do so only when I stop the cursor move

22:40 <prahal__> LiquidAcid: drmModeSetPlane

22:40 <prahal__> the hw cursor that is

22:40 <LiquidAcid> prahal__, then you're not using atomic

22:42 <prahal__> is it worth fixing kernel to still cope with non atomic armsoc or best forget about it and port the whole driver (might be out of my league though :/ )

22:42 <prahal__> the whole armsoc ddx that is

22:43 <LiquidAcid> prahal__, see https://lists.freedesktop.org/archives/dri-devel/2017-April/138579.html

22:44 <LiquidAcid> i'm not sure though if that's going to work on exynos

22:44 <prahal__> I am down to 3 commits on the kernel to get armsoc back on trail

22:44 <LiquidAcid> mixer windows can only be updated during vblank time

22:44 <LiquidAcid> or rather, the non-shadow register of the mixer

22:46 <prahal__> this I read on kernel commit 14e022f3041d5 but that whole pending commit handling is gone now (this is the 1/3 of the commit that broke armsoc)

22:48 <LiquidAcid> iirx the pending commit handling was moved to core, or rather, common core code is now used

22:57 <prahal__> I am puzzled :)

22:59 <prahal__> "async atomic update" looks fine , but

23:02 <prahal__> they ported

23:02 <LiquidAcid> ?

23:03 <prahal__> oups :) *ported* exynos to a new code that cannot cope with two planes changes at once (desktop v cursor planes) ?

23:04 <LiquidAcid> not sure what you mean

23:05 <LiquidAcid> atomic updates just happen on the next vblank