Yeah, that's my bad. If we had been talking about the 9560 I would have flagged it up (as I did here https://forums.bit-tech.net/index.php?threads/laptop-for-£2k.332885/#post-4397276), but for whatever reason the light bulb didn't go on here. You may not have an issue, and the problems may have been resolved. If I'm banking on one vendor or another for bulletproof connectivity though, my money's on Intel rather than the alternative. Even when ordering mine I was thinking I would have preferred it with Intel, not having researched any of the potential issues with the Killer card. When I had the problem, forgetting APs, restarting, un/reinstalling drivers didn't sort anything. It was restarting the AP that allowed it to reconnect (meanwhile, every other device in the house was doing just fine). Just as well I was at home, as restarting the AP isn't always an option. It was out of there shortly thereafter, as there are many scenarios where that could have presented serious issues beyond just pissing me off for a bit. You can always call dell and likely have a replacement intel card sent out free of charge, as many other users have reported following issues (or an on-site engineer depending on what support you went for). I chose not to do this and order my own because I needed something immediately, and Amazon prime could sort me out more quickly than Dell would have been able to. In the 9560 at least, it's a quick and easy swap, assuming you have a T5 on hand. Wouldn't that have been nice. Mine decided to start being flaky in May. Maybe there's an issue that was resolved in Feb, but there's another issue which was present in its latest drivers at that point. I decided not to fight it and just swap out. Maybe the perception is that Killer Wifi is high end compared to the bog standard intel that's in everything else on the market? It surprised me too.
Aye, I had a look. No nasty 'WARRANTY VOID' stickers, at least - and I've got a "TELECOM MUNICATIONS TOOLS" (as the side says) set with a T5 bit and spudger, even if they are made of the finest Chinesium.
It's here! It's shiny! The wireless blows goats! Upgraded to the latest 4.10 kernel (Ubuntu 16.04.3 LTS, up from the 4.4-based 16.04 it came with), no joy. It'll connect on 5GHz but not transmit or receive anything; works fine on 2.4GHz, but that's cold comfort. Guess I'll be getting the screwdriver out at some point! EDIT: Swapped out for an Intel 8265, and I can connect via 5GHz at last! The signal strength in the office ain't the best, though, so it's gracefully falling back to 2.4GHz - which is fine, because I'm getting 56Mb/s out of my ~60Mb/s VDSL line. In other words: close enough! The only confusing point: the Broadcom (Killer) Wi-Fi card had MAIN marked as white and AUX marked as black, with the white cable going into MAIN and the black cable going into AUX. The 8265, by contrast, was maked as black for MAIN and white for AUX. I put the cables back as per their original connection - white to MAIN and black to AUX - but it's harshing my calm knowing that the cables don't match the colour coding now...
I've knocked up a quick little script which works perfectly for me: the first two lines enable palm detection (so if you swipe something bigger than a finger, fnar-fnar, it won't move the cursor) while the last line disables the touchpad altogether while typing for both motion and clicking then enables it again after a short delay. I can confirm it's absolutely working a treat here: I've got my cursor hovering over another window and keep tapping the touchpad with my thumb as I'm typing and nowt's happening. The only way I can get something to happen is by pressing the touchpad hard enough to activate the physical click - which appears to still be active. I'm not likely to do that while typing, though, so I'm happy. The script is here. Save it, make it executable, stick it in your startup applications, job should be a good 'un. Just be aware that if you're not on the exact same model of XPS as me you may need to change the string it searches for in order to find the touchpad. Hit the terminal and type xinput list to get something a bit like this: Code: blacklaw@xerxes:~/bash-scripts$ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ DLL075B:01 06CB:76AF Touchpad id=10 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Power Button id=8 [slave keyboard (3)] ↳ Sleep Button id=9 [slave keyboard (3)] ↳ Intel Virtual Button driver id=11 [slave keyboard (3)] ↳ Intel HID events id=12 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=13 [slave keyboard (3)] ↳ Dell WMI hotkeys id=15 [slave keyboard (3)] ↳ Integrated_Webcam_HD id=16 [slave keyboard (3)] Mine's called 'DLL75B:01 06CB:76AF Touchpad', so 'DLL75B' is plenty to uniquely identify it. If yours is called something else - I've seen talk of XPSes where it's called 'Dell Somethingorother Touchpad' or 'Synaptics Somethingorother' - then change 'DLL75B' in the two lines of the script accordingly. Hope it works for you - it certainly has for me!
Isn't an antenna an antenna? I wouldn't have though it would make any difference although according to this post on the Intel forums antenna 1 is for Wi-Fi and bluetooth whereas antenna 2 is solely for Wi-Fi.
Only in as much as a tyre is a tyre. Even basic whip antennae need to be cut to the correct length for the wavelength used, and when you start using patch antennae, MIMO, phased transmission (beamforming and steering) etc, then you can't just plug in random cables and hope for the best.
Well, this is annoying: I rebooted to install a new graphics firmware, and now the trackpad is active while I'm typing despite running syndaemon with the correct invocation. Bumholes. So, what's changed, I wonder? EDIT: Interesting: if I cold-boot, disable-touch-while-type doesn't work; if I suspend then resume, it does. That'd be a fine workaround, *but* now the thing's decided to disable all the neat-o features it should have - like two-finger scrolling and tap-to-click. Weeeeeeeeeird. EDIT EDIT: Aha! It's because, for some reason, from a cold boot the touchpad shows up as both an I²C device and a PS/2 device, which is confusing the heck out of syndaemon. Code: blacklaw@xerxes:~$ xinput -list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ DLL075B:01 06CB:76AF Touchpad id=10 [slave pointer (2)] ⎜ ↳ SynPS/2 Synaptics TouchPad id=14 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Power Button id=8 [slave keyboard (3)] ↳ Sleep Button id=9 [slave keyboard (3)] ↳ Intel Virtual Button driver id=11 [slave keyboard (3)] ↳ Intel HID events id=12 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=13 [slave keyboard (3)] ↳ Dell WMI hotkeys id=15 [slave keyboard (3)] ↳ Integrated_Webcam_HD id=16 [slave keyboard (3)] So, change of plan: instead of putting the script in Startup Applications, I'm going to just run it manually after each cold boot - but only after suspending and resuming the machine first. Yes, that's stupid. Welcome to technology! EDIT EDIT EDIT: Sure enough, a cold boot followed by a suspend gives me this: Code: blacklaw@xerxes:~$ xinput -list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ DLL075B:01 06CB:76AF Touchpad id=10 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Power Button id=8 [slave keyboard (3)] ↳ Sleep Button id=9 [slave keyboard (3)] ↳ Intel Virtual Button driver id=11 [slave keyboard (3)] ↳ Intel HID events id=12 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=13 [slave keyboard (3)] ↳ Dell WMI hotkeys id=15 [slave keyboard (3)] ↳ Integrated_Webcam_HD id=16 [slave keyboard (3)] A quick run of my script now, and not before, and the trackpad is correctly disabled while typing and doesn't lose any of its shiny features. An annoyance, but hey - I'm on Linux, how often do I need to reboot anyway?! EDIT EDIT EDIT EDIT: So... there's a slightly unforeseen side-effect to disabling the touchpad while you type: you have to leave half a second between pressing a key and moving the cursor while playing a game. It doesn't differentiate. Basically makes 'em unplayable. I tried killing syndaemon while running the game, but that just made the trackpad stop working altogether. I guess a workaround is to reboot before you run a game, but that's not exactly a great solution. So, you get a choice: no accidental clicking while typing but no gaming either, or gaming and putting up with the occasional accidental click.
I'll tell you what, Dell's done an absolutely terrible job of optimising Linux on these things. Rough summary of what I've done off the top of my head: * Replace the Wi-Fi card * Upgraded from 16.04 to 16.04.3 (which bumps you to Linux 4.10.x) * Fixed the touchpad * Installed new video firmware (which enables hardware video acceleration in Firefox, for a start) * Enabled GPU-accelerated OpenCL * Enabled hibernation (there's plenty of room in the swap partition - it's 35GB, for some reason!) * Tweaked the power settings to boost battery life It's now, unsurprisingly, a fair whack faster and considerably more usable than it was out-the-box. None of those were big jobs, and I'd argue that they're all things Dell should have done before it ever left the factory.
Okay, now we're cooking with flamin' gas! This new version of the script is a lot smarter than the old one: Code: #!/bin/bash # Script to activate palm detection on the Dell XPS 13. if `xinput -list | grep -q SynPS`; then echo ERROR: SynPS/2 device found. echo Suspend and resume your laptop, then run this script again. exit 1 fi echo Killing currently-running syndaemon... killall syndaemon > /dev/null 2>&1 echo Enabling palm detection... xinput set-prop `xinput list | grep DLL075B | cut -d= -f2 | cut -f1` "Synaptics Palm Dimensions" 5, 5 xinput set-prop `xinput list | grep DLL075B | cut -d= -f2 | cut -f1` "Synaptics Palm Detection" 1 echo Enabling three-finger-tap for middle click... synclient TapButton3=2 if [ "$1" == "--type-disable" ] || [ "$1" == "-td" ]; then echo Trackpad disabled while typing. syndaemon -i 0.2 -K -R -d synclient TouchpadOff=0 else echo Trackpad enabled while typing. synclient TouchpadOff=0 fi echo Done! exit 0 It now has a -td (or --type-disable) switch. When run with said switch, the touchpad is disabled while typing based on a shortened 0.2-second delay ('cos I was finding the 0.5 second delay a bit annoying.) Without said switch, the script only enables palm detection and leaves the touchpad active while typing - meaning you can play games again. Yay! Last little bit of cleverness is the synclient TouchpadOff=0 command: turns out that sometimes when you're running syndaemon in daemon mode and kill it to re-enable the touchpad while typing (for gaming, in other words), it would default to the touchpad being off - hence why the touchpad died on me when I tried to disable syndaemon to play my game. That line just turns it back on again (or, technically, turns it being off off - 'cos that's a sensible way to think of it, synclient developers...) EDIT: Oh, and as an added bonus the script will now gracefully exit if it finds the SynPS/2 device, telling you to suspend and resume before trying again. *And* it enables three-finger middle-click, which is for some reason disabled by default. So: Code: blacklaw@xerxes:~$./xps13-palm-detect.sh Killing currently-running syndaemon... Enabling palm detection... Enabling three-finger-tap for middle click... Trackpad enabled while typing. Done! blacklaw@xerxes:~$ <insert playing a game here> blacklaw@xerxes:~$./xps13-palm-detect.sh -td Killing currently-running syndaemon... Enabling palm detection... Enabling three-finger-tap for middle click... Trackpad disabled while typing. Done! blacklaw@xerxes:~$ <insert doing typing work here> Ta-da! Give that a try, @theshadow2001 - see if it fixes yer problem. EDIT EDIT: I could go a step further and turn the script into a toggle: if disabled-while-typing is on turn it off, and if disabled-while-typing is off turn it on. That way you could just stick it in the Menu and click it to toggle between Work Mode and Game Mode. But first, paid work beckons...
I've tried Windows - my first version was Windows 3.1. I've tried macOS - I had a MacBook Air for four years. Still, I come back to Linux as the only OS that doesn't drive me completely bleedin' insane. Well, unless going back to Amiga Workbench is an option.
I'm pretty sure it is an option, but you'll have to accept some rather major compromises I was thinking the other day just how ahead of its time Workbench (and the Amiga in general) was. Shame Commodore did a Commodore really.
Well, yes. Which reminds me, I haven't played with RISC OS on a Raspberry Pi in years. I should fix that.
Job's a good 'un: a script which flicks betwix Work Mode (touchpad disabled while typing) and Game Mode (touchpad enabled while typing.) One-click, baby, one click!