Dell XPS 13 9350 Late 2015

Asriel · 2016-11-29 20:08:57

OdinEidolon wrote:

Thanks, I will try this on my 9550.

Just keep in mind - I have 9350 so intel is the only card for me, and I have no idea if this settings will work with bumblebee and NVidia.

OdinEidolon · 2016-11-29 21:04:42

Asriel wrote:

OdinEidolon wrote:
Thanks, I will try this on my 9550.
Just keep in mind - I have 9350 so intel is the only card for me, and I have no idea if this settings will work with bumblebee and NVidia.

That should have no impact whatsoever in theory. Will report back in a few days.

piemonkey · 2016-11-29 21:30:51

nos1609 wrote:

Successfully activated full touch support in firefox on 9350. Anybody needs this info posted here?

I'd love this info too. I may have only got the touch screen to get the higher specs, but it's a shame not to use it for something.

@Damige
Thanks for putting the time into xpsfan, I'll probably end up forking and tweaking for my own use-case, i.e. hooking into a power manager, as I don't have any problems with heat or fans generally, just want more battery life.

Any idea why your linux-nvme AUR is getting gpg failures?

damige · 2016-11-29 22:32:19

piemonkey wrote:

nos1609 wrote:
Successfully activated full touch support in firefox on 9350. Anybody needs this info posted here?
I'd love this info too. I may have only got the touch screen to get the higher specs, but it's a shame not to use it for something.
@Damige
Thanks for putting the time into xpsfan, I'll probably end up forking and tweaking for my own use-case, i.e. hooking into a power manager, as I don't have any problems with heat or fans generally, just want more battery life.
Any idea why your linux-nvme AUR is getting gpg failures?

Same here! battery 4tw!

something strange is going on there... the vanilla archlinux package for 4.8.11 does not build either (https://www.archlinux.org/packages/core/x86_64/linux/).
Its fixable by commenting out both .sign files in source(). and removing both 'SKIP' from sha256sums()

I could change the pkg but it would be less secure, which i do not prefer.

Edit: it seems fine again now... can you confirm. Have not touched a thing :-/
Edit2: i noticed gnupg got a recent update, maybe its related?

Last edited by damige (2016-11-29 23:05:04)

frank604 · 2016-11-30 01:45:25

@damige, can you go over the thinking of creating xpsfan? I'm just going over the scripts now but I wanted to know what sparked you to create them, what use-case they helped you in. Thanks for sharing as always. Love community dev!!

I only ask the above because I don't notice the fans kicking in too often. Only time they kick in is when I'm compiling, but I do most of that at work and use it leisurely when I'm at home (light browsing, music, video, etc).

What I find really cool about it is GPU freqs! Never thought to do that. Will be interesting to see which freq gets me best battery life while watching video (stream or local).

Edit: Some fail safe to add before releasing to public would be to watch temps and override user selection when temp >= X degrees

Last edited by frank604 (2016-11-30 01:47:10)

damige · 2016-11-30 07:23:42

frank604 wrote:

@damige, can you go over the thinking of creating xpsfan? I'm just going over the scripts now but I wanted to know what sparked you to create them, what use-case they helped you in. Thanks for sharing as always. Love community dev!!
I only ask the above because I don't notice the fans kicking in too often. Only time they kick in is when I'm compiling, but I do most of that at work and use it leisurely when I'm at home (light browsing, music, video, etc).

Thanks! I was just searching for ways to make the device use less power, combined with a few workloads i have where the fan would just kick in for 20 seconds and go off again repeatedly, seemingly unneccessarly. I just thought: lets look into that.

At this time its a bit of a mess with a lot of scripts that could be merged into one tool. But that will come when i figure out which settings are most effective.

frank604 wrote:

What I find really cool about it is GPU freqs! Never thought to do that. Will be interesting to see which freq gets me best battery life while watching video (stream or local).
.

For me its easy. On my 1080p device there is no reason to go above minimum freq (300mhz, iris 540) on FHD. All work loads are fine. With one exception: gaming. There i find that for each game there is benefit to find the optimum balance between gpu and cpu freq.

I made a new script (gpulowhigh) that toggles between stock and minimum frequencies. As that currently seems to be my most used.

Edit: script is not finished though as it assumes a 300mhz low and 1050mhz high. This is probably different on 530 or kabylake cpus.

frank604 wrote:

Edit: Some fail safe to add before releasing to public would be to watch temps and override user selection when temp >= X degrees.

No problem, I will make this.

Last edited by damige (2016-11-30 07:39:26)

nos1609 · 2016-11-30 10:12:53

@piemonkey & @rgzfxf6bhu modified the original post with the info;)

Last edited by nos1609 (2016-11-30 10:13:41)

piemonkey · 2016-11-30 19:28:57

damige wrote:

something strange is going on there... the vanilla archlinux package for 4.8.11 does not build either (https://www.archlinux.org/packages/core/x86_64/linux/).
Its fixable by commenting out both .sign files in source(). and removing both 'SKIP' from sha256sums()
I could change the pkg but it would be less secure, which i do not prefer.
Edit: it seems fine again now... can you confirm. Have not touched a thing :-/
Edit2: i noticed gnupg got a recent update, maybe its related?

It still complained for me. Obviously I removed the offending files before trying to run again, but no joy. Surely since the sha256sums haven't changed and pass both times, the files themselves can't have changed, just the .sign files? It's even weirder that it now seems to be working for you.

@nos1609 Thanks for the info, but doesn't work for me, are you using synaptics or libinput? Come to think of it, I don't think multitouch works on anything for my touchscreen, did you have to do anything special to configure that?

damige · 2016-11-30 22:59:23

piemonkey wrote:

damige wrote:
something strange is going on there... the vanilla archlinux package for 4.8.11 does not build either (https://www.archlinux.org/packages/core/x86_64/linux/).
Its fixable by commenting out both .sign files in source(). and removing both 'SKIP' from sha256sums()
I could change the pkg but it would be less secure, which i do not prefer.
Edit: it seems fine again now... can you confirm. Have not touched a thing :-/
Edit2: i noticed gnupg got a recent update, maybe its related?
It still complained for me. Obviously I removed the offending files before trying to run again, but no joy. Surely since the sha256sums haven't changed and pass both times, the files themselves can't have changed, just the .sign files? It's even weirder that it now seems to be working

As stated on aur :

"Solved it by manually receiving the keys for Linus Torvalds and Greg Kroah-Hartman:

gpg --recv-keys ABAF11C65A2970B130ABE3C479BE3E4300411886
gpg --recv-keys 647F28654894E3BD457199BE38DBBDC86092693E"

This fixes the issue, probably caused by the gnupg update.

belette · 2016-12-01 09:41:31

I confirm it is working much better !
EDIT: I was probably too happy too quickly!
After hitting the power bouton of the Dock and hitting again it works as expected.
I left the computer in sleep for 1 hour and when I came back I got a crash with lot of message like :

 
drm:intel_wait_ddi_buf_idle [i915] *ERROR* Timeout waiting for DDI BUF B idle bit
drm:intel_dp_start_link_train [i915] *ERROR* failed to train DP, aborting
drm:intel_dp_set_idle_link_train [i915] *ERROR* Timeout waiting for DP idle patterns

I keept Intel drivers.
Just a strange/annoying thing is that when I connect the USB type c again, my xfce session stops and I get back to my slim again..
So I loose all my current work... Do you have the same type of issue on your DE/LM ?

kang wrote:

Kernel 4.8.11 re-fixes the issue with the display port disconnect and the modesetting DDX \o/ (@belette)

Last edited by belette (2016-12-01 14:14:52)

kgizdov · 2016-12-01 14:40:54

Guys,

Dell has released an update for the TPM to convert it from v1.2 to v2.0. However, it seems (according to the Arch Wiki) that the kernel and tcsd do not have support for TPM 2.0. I looked around online and couldn't find enough info to support this. Does anyone know if that's the case or if it's safe to update the TPM. I don't want to lose functionality as there is no way to downgrade, as far as I can tell.

kang · 2016-12-02 06:38:43

belette wrote:

I confirm it is working much better !
EDIT: I was probably too happy too quickly!
After hitting the power bouton of the Dock and hitting again it works as expected.
I left the computer in sleep for 1 hour and when I came back I got a crash with lot of message like :
 
drm:intel_wait_ddi_buf_idle [i915] *ERROR* Timeout waiting for DDI BUF B idle bit
drm:intel_dp_start_link_train [i915] *ERROR* failed to train DP, aborting
drm:intel_dp_set_idle_link_train [i915] *ERROR* Timeout waiting for DP idle patterns
I keept Intel drivers.
Just a strange/annoying thing is that when I connect the USB type c again, my xfce session stops and I get back to my slim again..
So I loose all my current work... Do you have the same type of issue on your DE/LM ?
kang wrote:
Kernel 4.8.11 re-fixes the issue with the display port disconnect and the modesetting DDX \o/ (@belette)

No such issues here - using modesetting DDX though, with the intel one it unfortunately does not work well (i dont have the error log, but screen does not wake up - sometimes system freeze and ihavent looked at the log afterwards, just switched to modesetting)
I use sddm and plasma

belette · 2016-12-02 19:54:50

Hi Kang,

Thanks for the modesetting advice it is a huge improvement for me!
It seems I got it right now!
Just to confirm, have you keep i915 in your mkinitcpio?
On my side I did but remove all the kernel parameters on my grub

Have you noticed tearing on your side?
I definetly have huge tearing with modesetting and I don't know how to fix it as tearfree option seems to do nothing on modesetting.
On intel drivers the tearfree option was working great instead. Dont hesitate to share your experience here

kang wrote:

belette wrote:
I confirm it is working much better !
EDIT: I was probably too happy too quickly!
After hitting the power bouton of the Dock and hitting again it works as expected.
I left the computer in sleep for 1 hour and when I came back I got a crash with lot of message like :
 
drm:intel_wait_ddi_buf_idle [i915] *ERROR* Timeout waiting for DDI BUF B idle bit
drm:intel_dp_start_link_train [i915] *ERROR* failed to train DP, aborting
drm:intel_dp_set_idle_link_train [i915] *ERROR* Timeout waiting for DP idle patterns
I keept Intel drivers.
Just a strange/annoying thing is that when I connect the USB type c again, my xfce session stops and I get back to my slim again..
So I loose all my current work... Do you have the same type of issue on your DE/LM ?
kang wrote:
Kernel 4.8.11 re-fixes the issue with the display port disconnect and the modesetting DDX \o/ (@belette)
No such issues here - using modesetting DDX though, with the intel one it unfortunately does not work well (i dont have the error log, but screen does not wake up - sometimes system freeze and ihavent looked at the log afterwards, just switched to modesetting)
I use sddm and plasma

Last edited by belette (2016-12-06 00:07:22)

belette · 2016-12-02 23:15:09

For the ones who are using Dock WD15 and full disk encryption.
What do you put guys into your mkinitcpio for being able to use an USB keyboard to write the passphrase ?
Not able to find it and I tried different options, but it is like usb c is recognize / activated later on the boot...
Many thanks

AUTOREPLY : not an issue with mkinitcpio but with EFI where one option needs to be activated for this to work:
Thunderbolt boot support
That's it !

Last edited by belette (2016-12-03 10:08:08)

zetxx · 2016-12-06 16:31:20

just looping

]Hi Niranjan and Elin-

I tagged a new test version of the driver:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/tag/?h=20160512-nvme-test

Niranjan, if you're willing to pound on this some more, there are a
couple of interesting tests you could do:

1. The patch series, as is, should work on your system -- I've added a
quirk to mask of APST support on your buggy drive.  Could you see if
it does indeed work?

2a. Try it again with the Samsung quirk reverted -- that's the patch
called 'nvme: Add a quirk to disable APST on a buggy Samsung device'.
You can revert it manually or with 'git revert'.  Boot it with
nvme_core.default_ps_max_latency_us=0.  Hopefully your system will
work.  Please send the output of 'dmesg |grep nvme' when you boot lke
this.

2b.  After doing that, do this as a single bash command

# echo 25000 > /sys/class/nvme/nvme0/power/pm_qos_latency_tolerance_us;
echo 0 > /sys/class/nvme/nvme0/power/pm_qos_latency_tolerance_us

That should produce some logs.  Can you send them?

2c. Do:

echo 25000 > /sys/class/nvme/nvme0/power/pm_qos_latency_tolerance_us

and let me know if your system dies again.

Elin- if you want to play with this patch series, it should Just Work
(tm) on anything except the one known buggy Samsung device.  Do to the
debugging patch in the series, you may get some extra log messages,
but it should be harmless.

Thanks!

damige · 2016-12-06 19:05:28

zetxx wrote:

just looping

]Hi Niranjan and Elin-

I tagged a new test version of the driver:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/tag/?h=20160512-nvme-test

Niranjan, if you're willing to pound on this some more, there are a
couple of interesting tests you could do:

1. The patch series, as is, should work on your system -- I've added a
quirk to mask of APST support on your buggy drive.  Could you see if
it does indeed work?

2a. Try it again with the Samsung quirk reverted -- that's the patch
called 'nvme: Add a quirk to disable APST on a buggy Samsung device'.
You can revert it manually or with 'git revert'.  Boot it with
nvme_core.default_ps_max_latency_us=0.  Hopefully your system will
work.  Please send the output of 'dmesg |grep nvme' when you boot lke
this.

2b.  After doing that, do this as a single bash command

# echo 25000 > /sys/class/nvme/nvme0/power/pm_qos_latency_tolerance_us;
echo 0 > /sys/class/nvme/nvme0/power/pm_qos_latency_tolerance_us

That should produce some logs.  Can you send them?

2c. Do:

echo 25000 > /sys/class/nvme/nvme0/power/pm_qos_latency_tolerance_us

and let me know if your system dies again.

Elin- if you want to play with this patch series, it should Just Work
(tm) on anything except the one known buggy Samsung device.  Do to the
debugging patch in the series, you may get some extra log messages,
but it should be harmless.

Thanks!

Thanks, and woops!!!

The buggy samsung device seems to be "SM951 NVMe SAMSUNG 256GB" ... The one many of us (including me) use.
https://git.kernel.org/cgit/linux/kerne … acb26c708c

Plawucht · 2016-12-09 20:42:20

damige wrote:

[...] the fan would just kick in for 20 seconds and go off again repeatedly, seemingly unneccessarly. I just thought: lets look into that. [...]

I had the same issue. What fixed it really easily was changing the thermal paste. The stuff Dell use in their assembly process is horrible. It has to be really cheap stuff, I can't really explain why they use it; they just do. Even some of their servers get this shit slapped on. Often times, like in my case(s), way too much. I cleaned it with alcohol and changed it against some by Noctua (iirc) I had laying around. Now my temps while browsing in a 23°C room on my lap is below 50°C. On a desk it's even lower. (chromium with 150+ tabs, multiple evince instances and rstudio)
A few weeks ago I checked if the paste moved, but so far it held up really good. My fan only kicks in when compiling. Even while charging and compiling, I can pretty much keep the CPU around at 3GHz for around 2 minutes, then 2.7GHz and about 94°C for a longer time, no crashes. I just hate touching the device then.

And this is why I want to thank again for putting up with me over on github Because of you compiling the kernel and uploading it, I don't burn my fingers after compilation
Also, xpsfan is a really awesome tool! I am planning on bying a XPS 15 as soon as the new one drops. With the 1060m it might get, I sure will be in need of the tool!

Cheers mate! Again, thanks!

Asriel · 2016-12-10 10:33:25

Agree - paste is terrible cheap crap, and Dell just dumps a hell lot of it so all my CPU was covered with thick layer of paste. Repasted it with Arctic MX-4 and also added some thermal rubber on top of the radiator so there is now thermal contact between cooling pipe and metal back cover. It gets really hot on compilation now - but the top panel remains cool all the time.

Asriel · 2016-12-11 06:42:01

Updated version of my kernel - based now on 4.9-rc8, pm patches from next, some patches from drm-intel-nigtly amd one old regression psr patch applied - looks good for me so far, have not seen any flickering since boot it (6 hours) , power consumption at ilde 2.6 watts with firefox (static page - no animations/scripts running on active page), thunderbitd, skype, viber, compiz.

https://yadi.sk/d/kJmac2VF32yaMk

Just some history around this kernel - I ve set up Linux on my XPS 13 9350 since I got it, the main difference I had a 1TB disk which is SATA based so I've swapped my 256G Samsung with it immediately, and then started fighting with the graphics issues. The most power saving is happening with PSR and FBC enabled - but as soon as i enable that flickering happened, freezing of the screen and so on. Switching PSR off helps - no flicker, no freeze - but the power usage is about 1W more. Middle way - use psr=3 (standby of link instead of poweroff) - get rid of freeze but still have about 0.4W extra power usage over full scale psr=1. So I've started building kernes based on -next patch series from kernel.org, and applying PSR related patches from patchwork.org. And once the combination worked - I had PSR and FBC and GUC working. So I've simply copied include/drm, include/uapi/drm , drivers/gpu/drm folders from that very experimental kernel ovcer 4.9-rc series and continued to apply changes which were appliable over that i915 code base.

Once in a while I try to build drm-intel-nightly hoping that mainstream driver have finally fixed PSR - but no luck so far, my latest try was yesterday. So i've just copied my drivers from 4.9-rc2 over 4.9-rc8 , alpplied couple of patches from patchwork.org and Linus's Git tree from kernel.org - so that's it. Unfortunately I have no idea what exactly makes FBC work in this code but brakes it in the drm-intel-nightly and mainstream kernels - so just offer my kernel as it is.

Last edited by Asriel (2016-12-11 10:53:24)

Plawucht · 2016-12-11 10:58:57

Hey @Asriel, would you please link me to the configs and patches you used for compilation? Maybe on Github or something along those lines
Since you use AHCI, maybe a brainchild of yours and Damige's work would be even better at saving power. (Unless Damige already has done the same modifications).
Thank you

Asriel · 2016-12-11 11:43:33

For NVME I had not used any patches this time - it is pure vanilla 4.9-rc8, so please try to apply Damige's patches over it. All I did is mainly inside i915-drm code.

The only thin - Ive applied PM and THERMAL patches from linux-next tree from 05.12. With the later patches I had hibernation broken, so I had reverted back to 05.12 and never check again

https://git.kernel.org/cgit/linux/kerne … linux.git/ - I usually check "merge brunch" patches here for stabe

https://git.kernel.org/cgit/linux/kerne … -next.git/ - and here for pm and thermal

damige · 2016-12-12 01:03:34

Plawucht wrote:

damige wrote:
[...] the fan would just kick in for 20 seconds and go off again repeatedly, seemingly unneccessarly. I just thought: lets look into that. [...]
I had the same issue. What fixed it really easily was changing the thermal paste. The stuff Dell use in their assembly process is horrible. It has to be really cheap stuff, I can't really explain why they use it; they just do. Even some of their servers get this shit slapped on. Often times, like in my case(s), way too much. I cleaned it with alcohol and changed it against some by Noctua (iirc) I had laying around. Now my temps while browsing in a 23°C room on my lap is below 50°C. On a desk it's even lower. (chromium with 150+ tabs, multiple evince instances and rstudio)
A few weeks ago I checked if the paste moved, but so far it held up really good. My fan only kicks in when compiling. Even while charging and compiling, I can pretty much keep the CPU around at 3GHz for around 2 minutes, then 2.7GHz and about 94°C for a longer time, no crashes. I just hate touching the device then.
And this is why I want to thank again for putting up with me over on github Because of you compiling the kernel and uploading it, I don't burn my fingers after compilation
Also, xpsfan is a really awesome tool! I am planning on bying a XPS 15 as soon as the new one drops. With the 1060m it might get, I sure will be in need of the tool!
Cheers mate! Again, thanks!

Asriel wrote:

Agree - paste is terrible cheap crap, and Dell just dumps a hell lot of it so all my CPU was covered with thick layer of paste. Repasted it with Arctic MX-4 and also added some thermal rubber on top of the radiator so there is now thermal contact between cooling pipe and metal back cover. It gets really hot on compilation now - but the top panel remains cool all the time.

Thanks! Great tips i will look into this. I do my compiling on my workstation (dual Xeon 24 threads) makes life quite a bit easyer ;-)

Asriel wrote:

Updated version of my kernel - based now on 4.9-rc8, pm patches from next, some patches from drm-intel-nigtly amd one old regression psr patch applied - looks good for me so far, have not seen any flickering since boot it (6 hours) , power consumption at ilde 2.6 watts with firefox (static page - no animations/scripts running on active page), thunderbitd, skype, viber, compiz.
https://yadi.sk/d/kJmac2VF32yaMk
Just some history around this kernel - I ve set up Linux on my XPS 13 9350 since I got it, the main difference I had a 1TB disk which is SATA based so I've swapped my 256G Samsung with it immediately, and then started fighting with the graphics issues. The most power saving is happening with PSR and FBC enabled - but as soon as i enable that flickering happened, freezing of the screen and so on. Switching PSR off helps - no flicker, no freeze - but the power usage is about 1W more. Middle way - use psr=3 (standby of link instead of poweroff) - get rid of freeze but still have about 0.4W extra power usage over full scale psr=1. So I've started building kernes based on -next patch series from kernel.org, and applying PSR related patches from patchwork.org. And once the combination worked - I had PSR and FBC and GUC working. So I've simply copied include/drm, include/uapi/drm , drivers/gpu/drm folders from that very experimental kernel ovcer 4.9-rc series and continued to apply changes which were appliable over that i915 code base.
Once in a while I try to build drm-intel-nightly hoping that mainstream driver have finally fixed PSR - but no luck so far, my latest try was yesterday. So i've just copied my drivers from 4.9-rc2 over 4.9-rc8 , alpplied couple of patches from patchwork.org and Linus's Git tree from kernel.org - so that's it. Unfortunately I have no idea what exactly makes FBC work in this code but brakes it in the drm-intel-nightly and mainstream kernels - so just offer my kernel as it is.

I currently use psr=2 (standby link) i think your 3 was a typo? 2 works fine for me. It would be nice if we could find specific commit(s) that fixes psr=1 for the xps13. I have never seen 2.6 watts, the best average i can do (low brightness, in plasma with wifi) is ~3.5w. Even in wayland with modeset and psr=1 (works for about 70% of the time) i only get about ~3.2w avg.

I have updated linux-nvme to the latest patchset from andy and also moved to the 4.9 train. Keep in mind though guys that andy disabled APST for the SM951 256GB nvme drive (the one most of us use). I have not included this patch, so APST is still enabled. Things may go wrong, but its fine for me over the last 4h. Let me know how it goes!

I have also been trying some new things in the xps_fan project. Systemd service to set the clockspeed of the gpu low on boot. As i never need it higher unless gaming, and when i do i stop the service. This will be included in the PKGBUILD on github over next week. Hopefully with some other new things im wanting to try.

Last edited by damige (2016-12-12 01:06:19)

Asriel · 2016-12-12 03:21:32

Actually whatr I noticed is that applying PM patch from -next series over 4.9-rc (and I believe 4.9 release as well ) - reduce power usage for about 0.5W. I really do not know what in my kernel make psr=1 work - If I knew it then othing would stop to submit patch fo drm-intel team. I had some ideas that this particular patched is the key couple of times - but reapplying it over drm-intel-nighty did not solve psr issue.

I do not use wayland, and my version is FHD - so it is and advantage before high res touchscreens in terns of power

and yes - psr=2, it was a mistype. I've tried both options and there was a differemce between psr=2 and psr=1, about 0.3-0.4 watts on idle. But psr=2 is stable on current version fo driver, but psr=1 more or less working on my hacked version only.

Last edited by Asriel (2016-12-12 04:58:49)

belette · 2016-12-12 16:49:49

Reply to myself for future reference and to save some time for the others.

I have deleted i915 from my mkinitcpio and it is ok.

For tearing, installing compton (pacman -S compton) is giving me very good results and I got now the same performance/tearing free with modesetting DMX than my old intel drivers!

The last and very annoying point is external screen detection with the WD15 dock.
The first time I plug the WD15 through usb type c everything is working great, I can put my laptop to sleep&wake up 10 times with no problem.
When I disconnect the usb type c and re-plug it : most of the time my external screen stay black.

Doing a xrandr shows me sometimes only my XPS pannel and nothing else, sometimes I can still see my external screen but no signal is sent even if I do a xrandr --auto.

I tried to use

sudo sh -c "echo 1 > /sys/bus/pci/devices/0000:02:02.0/remove"
sudo sh -c "echo 1 > /sys/bus/pci/rescan"

But nothing better.
Sometimes disconnecting usb type c and reconnecting multiple times and my screen wake up !

Any idea on your side from the WD15 users?

Many thanks

belette wrote:

Hi Kang,
Thanks for the modesetting advice it is a huge provement for me!
It seems I got it right now!
Just to confirm, have you keep i915 in your mkinitcpio?
On my side I did but remove all the kernel parameters on my grub
Have you noticed tearing on your side?
I definetly have huge tearing with modesetting and I don't know how to fix it as tearfree option seems to do nothing on modesetting.
On intel drivers the tearfree option was working great instead. Dont hesitate to share your experience here
kang wrote:
belette wrote:
I confirm it is working much better !
EDIT: I was probably too happy too quickly!
After hitting the power bouton of the Dock and hitting again it works as expected.
I left the computer in sleep for 1 hour and when I came back I got a crash with lot of message like :
 
drm:intel_wait_ddi_buf_idle [i915] *ERROR* Timeout waiting for DDI BUF B idle bit
drm:intel_dp_start_link_train [i915] *ERROR* failed to train DP, aborting
drm:intel_dp_set_idle_link_train [i915] *ERROR* Timeout waiting for DP idle patterns
I keept Intel drivers.
Just a strange/annoying thing is that when I connect the USB type c again, my xfce session stops and I get back to my slim again..
So I loose all my current work... Do you have the same type of issue on your DE/LM ?
No such issues here - using modesetting DDX though, with the intel one it unfortunately does not work well (i dont have the error log, but screen does not wake up - sometimes system freeze and ihavent looked at the log afterwards, just switched to modesetting)
I use sddm and plasma

frank604 · 2016-12-13 04:21:46

When wd15 bugs out, I have to remove power for 30seconds and then power back on and replug. Just a heads up. Normal use doesn't trigger this bug but constant configuration changes with xrandr makes this issue occur. Haven't nailed down steps to reproduce.

Arch Linux

#1151 2016-11-29 20:08:57

Re: Dell XPS 13 9350 Late 2015

#1152 2016-11-29 21:04:42

Re: Dell XPS 13 9350 Late 2015

#1153 2016-11-29 21:30:51

Re: Dell XPS 13 9350 Late 2015

#1154 2016-11-29 22:32:19

Re: Dell XPS 13 9350 Late 2015

#1155 2016-11-30 01:45:25

Re: Dell XPS 13 9350 Late 2015

#1156 2016-11-30 07:23:42

Re: Dell XPS 13 9350 Late 2015

#1157 2016-11-30 10:12:53

Re: Dell XPS 13 9350 Late 2015

#1158 2016-11-30 19:28:57

Re: Dell XPS 13 9350 Late 2015

#1159 2016-11-30 22:59:23

Re: Dell XPS 13 9350 Late 2015

#1160 2016-12-01 09:41:31

Re: Dell XPS 13 9350 Late 2015

#1161 2016-12-01 14:40:54

Re: Dell XPS 13 9350 Late 2015

#1162 2016-12-02 06:38:43

Re: Dell XPS 13 9350 Late 2015

#1163 2016-12-02 19:54:50

Re: Dell XPS 13 9350 Late 2015

#1164 2016-12-02 23:15:09

Re: Dell XPS 13 9350 Late 2015

#1165 2016-12-06 16:31:20

Re: Dell XPS 13 9350 Late 2015

#1166 2016-12-06 19:05:28

Re: Dell XPS 13 9350 Late 2015

#1167 2016-12-09 20:42:20

Re: Dell XPS 13 9350 Late 2015

#1168 2016-12-10 10:33:25

Re: Dell XPS 13 9350 Late 2015

#1169 2016-12-11 06:42:01

Re: Dell XPS 13 9350 Late 2015

#1170 2016-12-11 10:58:57

Re: Dell XPS 13 9350 Late 2015

#1171 2016-12-11 11:43:33

Re: Dell XPS 13 9350 Late 2015

#1172 2016-12-12 01:03:34

Re: Dell XPS 13 9350 Late 2015

#1173 2016-12-12 03:21:32

Re: Dell XPS 13 9350 Late 2015

#1174 2016-12-12 16:49:49

Re: Dell XPS 13 9350 Late 2015

#1175 2016-12-13 04:21:46

Re: Dell XPS 13 9350 Late 2015

Board footer