Dell Venue 10 Pro 5055 Screen Rotation in Gnome

in

I recently fished a Dell Venue 10 Pro out of a pile of old computers at work that were heading to recycling. It's a pretty underwhelming computer but I thought it might be fun to tinker with a linux tablet in anticipation of the PineTab being released sometime next year.

I threw Fedora 31 on it as a first attempt, partly because I like Fedora and mostly because I had a USB drive with the installer already handy. I realize this might not be the best distro for this underpowered tablet but I just wanted to check it out. It installed fine with one exception, the screen is rotated 90 degrees clockwise in gnome. It worked fine under LXDE though. I poked around looking for a simple screen rotation setting in gnome but didn't find anything. Google kept pointing me down the road of iio-sensor-proxy and something about an ACCEL_MOUNT_MATRIX which I sort of glossed over because it seemed overly complex for a simple screen rotation. Surely there is just a simple "rotate 90 degrees" setting somewhere, right?

Eventually I gave up on a simple solution and started to read through the accelerometer matrix stuff. It turns out it's not that complicated. There is a file containing information about how the accelerometer in any given device is mounted so the OS knows which readings on each axis, x, y, and z correspond to the physical world. This is recorded in a matrix of three rows and three columns. It's been 30 years since I learned linear algebra and everything I once knew about matrix math is long forgotten so I couldn't really figure out how the matrix itself works, I just got my settings through trial and error. You can read the details of the matrix documented in the kernel but it didn't really help me much.

If you look at the sensor file it contains instructions for adding your own custom entry. Essentially you just need to figure out your device modalias:

cat /sys/`udevadm info -q path -n /dev/iio:device0`/../modalias

For the Dell Venue it returned acpi:INVN6500: Then you can get your device DMI string:

cat /sys/class/dmi/id/modalias

which returns:

dmi:bvnDellInc.:bvrA07:bd12/30/2015:svnDellInc.:pnVenue10Pro5055:pvrA07:rvnDellInc.:rn0T2H9X:rvrA00:cvnDellInc.:ct8:cvrNotSpecified:

Then create the file /etc/udev/hwdb.d/61-sensor-local.hwdb with the contents below. NOTE: Whitepace matters, you need to start the ACCEL_MOUNT_MATRIX line with a blank space

sensor:modalias:acpi:INVN6500*:dmi:*xvnDell*:pnVenue10Pro5055*   ACCEL_MOUNT_MATRIX=0, -1, 0;1, 0, 0;0, 0, 1

You can see I simplified the DMI string above with asterisks rather than specify every detail. On your own system it probably doesn't matter, in fact you can skip the full DMI string entirely and just do something very simple like this:

sensor:modalias:acpi:INVN6500*:dmi*

This will match anything using the INVN6500 sensor which is fine because your machine only has one sensor, but I tried to format my string to match the style of other strings in the main systemd sensor file because I wanted to also submit a pull request to include this in the official project.

Now you just need to update your hardware database:

sudo systemd-hwdb update

If you get an error, you probably ignored the note above about whitespace. If you didn't get an error you can validate your setting worked by running the commands below. Or you can just reboot and see what happens.

sudo udevadm trigger
sudo udevadm info -export-db | grep ACCEL

I submitted a pull request to add the Dell Venue 10 Pro 5055 info to systemd so at some point in the future this will "just work" but If you are following this guide and have a different device for which you are trying to figure out the matrix, I can tell you what I figured out in my trial and error. The default matrix is the "identity matrix" which means the hardware and sensor are perfectly aligned by default. The identity matrix is:

1 0 0
0 1 0
0 0 1

The following matrix gave me the correct default orientation when docked to the keyboard but it would not rotate at all.

0 1 0
0 1 0
0 0 1

So, I think you should not have two ones in the same row or column which makes sense because I believe they represent which sensor is pointing up in a given orientation. This next matrix worked for two orientations but was flipped 180 degrees for the other two:

0 1 0
1 0 0
0 0 1

So finally flipping the first one to a negative one corrected the 180 degree issue:

0 -1 0
1 0 0
0 0 1

And so that is ultimately the value I used for the "ACCEL_MOUNT_MATRIX=0, -1, 0;1, 0, 0;0, 0, 1" setting.

UPDATE: My pull request was accepted to systemd. As minor as it is, I'm weirdly excited that my first real pull request was accepted to a project as important as systemd.

Linux Professional Institute

in
LPIC-1-Medium.png

I haven't really bothered with certifications for most of my career but I've been listening to the Linux Unplugged Podcast lately which lead me to checking out some of the training at Linux Academy. There seems to be a lot of interesting training content there, so I decided that if I'm going to take the courses that I should actually get the certs to go along with them. So I started at the beginning with just the entry-level LPIC-1 Linux Administrator certification. It's not much but it was easy to knock out right away before moving on to the interesting things.

New Raspbian Image

in ,

I finally got around to setting up the new Raspbian image tonight. So far I'm really impressed with how well things have progressed since the debian image I had been using. There is a nice config tool to help with a lot of the initial setup stuff, although I did have to do some config.txt modifications in order to get any video at all on boot.  It even has an option to resize the partition on next boot to fill your SD card.  It's still not what I would call "fast" for things like web browsing but for the short time I've been using it, it is noticeably better than the old debian image I had.  If you're not sure about upgrading, I'd say it's definitely worth the effort.  Of course one of the great things about the Raspberry Pi is that you can just pop in a different SD card so swapping the OS is a very minor compared to other PCs. I also put it in it's shiny new adafruit pi box which is very cool.  It's a very clever design and looks cool with the board exposed and the LEDs doing their thing inside.

 

Raspberry Pi US Keyboard Config

in ,

It seems the Debian Squeeze image for the Raspi uses a British keyboard layout by default.  Not surprising and easily fixed by editing /etc/default/keyboard and changing the line XKBLAYOUT=”gb” to XKBLAYOUT=”us".  While you're at it you might as well run "sudo dpkg-reconfigure tzdata" to fix your time zone too. I've also found other some weirdness here and there.  There are two entries in /etc/passwd for the user "pi" but only one in /etc/shadow.  I've disabled the user for now but I really should delete it.  There is also a sudoer entry for "suse" which doesn't even exist in /etc/passwd.  Probably someone copied sudoers over from a suse box?  But why would anyone do that?  It's odd but that's what jumping on early is all about.  Lots to fix and lots to learn.

Raspberry Pi Debian Squeeze Default Editor

in ,

It occurred to me this afternoon that I could just enable internet connection sharing on my iMac and then use its ethernet connection for the raspi.  I'm still going to get the wifi dongle working but this is actually a better solution for now.  That way I can more easily swap out different SD cards for different distros and not have to immediately mess with the wifi setup each time. So the first thing I did was to create myself a user account.  The second thing I did was to make myself a sudoer.  I launch visudo and wtf... I'm thrown into some sort of crazy editor that makes no sense.  Maybe nano or something, who knows?  There is a reason I learned vi:  it's like Visa, it's everywhere you want to be.  The only editor you can guarantee is going to be on any unix box you encounter is vi (or some vi clone like vim if you must be pedantic) so why waste time learning something else?  So anyway, I poked around looking for a .bashrc or .profile entry setting EDITOR to something moronic with no luck.  Eventually my buddy Google told me that visudo on debian is compiled to use /usr/bin/editor which is linked to [some stupid editor].  To fix it simply "rm /usr/bin/editor" and then "ln -s /usr/bin/vi /usr/bin/editor" and bob's your uncle.

 

SSH Compression

in ,

I still haven't gotten around to testing Dropbear but I did find that SSH has built-in compression that can improve performance over slow links.  So using the command: 

ssh -X -C user@host

Creates an X tunnel with compression which is much more usable for me.  It's still a bit slow but it is slow even on my LAN.  I'm still planning to see if Dropbear can squeeze a little more performance out of my old netbook.  Ultimately I don't think the Raspberry Pi will be much more powerful (if at all) than my netbook so every bit of performace optimization will help.

Dropbear SSH

in , ,

I don't really know what, if anything I'm going to do with this blog.  Probably nothing.  But for now, I'm going to use it as a public place to dump things that are interesting to me. For example I've been looking forward to the upcoming release of the Raspberry Pi.  I dug out my old Eee PC 701 netbook to start working on a few of my ideas for these little things.  I'm not sure performance-wise how they compare but the netbook is really feeling slow these days.  I just tried running firefox on it from work via SSH X forwarding and it was pretty much unusable.  I'm sure my home uplink speed is part of the issue but it seems like 1.5Mps should be adequate.  It's faster from a local LAN connection but still not great. Which brings me to the inspiration for this post.  I just stumbled across Dropbear on the rpi forums.  It's supposed to be a less resource intensive than OpenSSH.  I'll give it a try on the eeepc and if there is a noticeable difference I'll be sure to use it on the rpi.