DisplayPort on Ubuntu

monitorThere is an ongoing issue with using monitors in Ubuntu connected via DisplayPort: monitor shows black screen and "no input signal" after turning the monitor off and on manually

Turning off a DisplayPort-connected monitor is treated the same as disconnecting it, and somehow X11 does not recover from this. I have seen this error related to Nvidia and Radeon cards, but in my case I have a Intel HD4000, and the error is exactly the same.

And it happens with just all kind of monitors, including my Dell U3011. A proposed solution is to disable DDC/CI on the monitor itself, but this didn't solve anything for me.

A solution I have found is to press Ctrl+Alt+F6 (or +F5, etc), to open a TTY console, and then pressing Ctrl+Alt+F7 to get back to X11. But it works sporadically, sometimes having to press these keys several times, or creating new TTY consoles, like pressing Ctrl+Alt+F2 to create a TTY2 if the 6 had been already created before.

Other provided solution is to ssh from another machine and run:

env DISPLAY=:0 xset dpms force off
env DISPLAY=:0 xset dpms force on
In this case, the best option is to create a shell script /usr/local/bin/display-port-wake-up.sh with this content, open Settings, Keyboard, Shortcuts, and create a custom shortcut (in my case, Ctrl + Alt + W). This solution works always, but there is a catch: the shortcut is only available when the user is logged in, so if the system is asking the user password to unlock the screen. the shortcut will not work. In this case, it is needed to enter blindly the password, press Enter, and then press the shortcut.

Moving Ubuntu to separate disk

driveAfter a few weeks with my new Ubuntu installation, I was able to do all my usual tasks without missing OsX. So far, I have found only two issues: display port monitor not awaking some times, and some crashes in Steam.

But the main issue has appeared when trying to it setup for Android development... and running out of space. So, the original hackintosh disk, which was in standby, had to go, and the idea was to clone my existing installation to the other disk.

So I reformatted the hackintosh drive, just to find that I had removed the EFI partition that booted the Ubuntu system... My solution was to launch the Ubuntu installer, and install Ubuntu again on the new drive (the previous Hackintosh drive), taking care of having one EFI partition, plus a big ext4 one. Once I had Ubuntu installed, I launched again the installation system, mounted the old partition under /media/old, and the new one under /media/new, and then copied all the important files:

sudo cp -R --preserve=all bin/ etc/ home/ lib/ lib64/
            opt/ root/ run/ sbin/ usr/ var/ /media/new/

Then edit the file /etc/fstab to change the UUID of the disks, and presto!

Setting up Ubuntu

Ubuntu configurationSetting up a Ubuntu computer seems to be my fate of late. And each time I do it, I need to do the same Google searches: how to configure workspaces, how to define my shortcuts, how to make Guake start at runtime, etc

So I have collected all the steps I take to configure a Ubuntu machine, from a generic point of view, not describing all the applications I finally use, but definitely including all details to configure Ubuntu as I like it. It seems weird to show these steps for a Ubuntu 16.10 installation on the same day that Ubuntu 17.04 is published, but I will definitely comment on any changes.

Ciao, Hackintosh

ciao hackintoshI have been setting up my computers as Hackintoshes since 2009; currently I have a Mac laptop, with the latest Sierra installation, and a Dell laptop, running Ubuntu 16.10, plus two desktop computers, one running Windows Vista and Snow Leopard (yep, both run still perfectly fine), and the other with MacOs Sierra. At work I use exclusively Linux, and I had been wondering for a long time on my reasons to keep my Hackintoshes at home.

As of last weekend, this question has been answered, fare well, Hackintosh. I will keep the old desktop running Snow Leopard, and my Apple laptop running MacOs, but I definitely see no point on not using Ubuntu as my first OS choice. My choice is rather simple to do, as none of the programs I use lack a Linux version, with the exception of Evernote, which I can still handle via its Web interface.

Batch editing Google contacts

google contactsThe new Google contacts application is very nice. It looks great, and it offers good functionality, like merging of duplicates. Editing contacts works perfectly, but it can only be done one contact at a time. I was migrating contacts from a non smartphone, and the migration had converted them into an ugly 'Family name; surname' format, such as 'Trumpy; Donald'. And as slick as the user interface is, editing by hand over 300 contacts was a boring perspective.

Automation to rescue: export contacts, process them with a python script, import them again. Do, in Google Contacts, press 'More', then export, then read the popup warning and head to the old Google Contacts application, as the new one seems to be unable to export the contacts. Press again the More button, again on export, and choose Google CSV format.

The script to convert the contacts is as simple as:

 import csv
 with open('google.csv', newline='', encoding='utf16') as f:
     contacts=list(csv.reader(f))

 for contact in contacts:
     colon = contact[1].find(';')
     if colon > 0:
         name = "%s %s" % (contact[1][colon+1:], contact[1][0:colon])
         contact[0] = contact[1] = name

 with open('google-out.csv', 'w', newline='') as f:
     csv.writer(f).writerows(contacts)
     

This reads the exported google.csv file, and creates a new google-out.csv file; in the old Google Contacts application, remove now all contacts, and then initiate the Import process, passing the created file. Easy as pie.

The previous script shows a very basic transformation; the important aspects are: (1) it is needed Python 3 to run this script, as its CSV reader handles properly the unicode format. (2) The input format seems to be UTF-16 (it was definitely on my OsX machine). (3) However, it was reimported as UTF-8 without issues.