Because, even with Q-Fan enabled for the chassis fans and put on “silent” in the BIOS, they’re pretty loud, especially if like me you’re still using a mix of 80, 92 and 120 mm fans.

This guide has been written on Linux Mint 20, and is specifically for the Asus P6T Deluxe V2 motherboard. I hope the revision doesn’t matter. In case it does, I’m sorry: you’re out of luck.
Information here could apply to other Asus motherboards, but I’ve still not done other tests.

Of course, the obvious disclaimer: the following procedure is provided as-is.
My computer is still up and running (quieter than before), but if your CPU fan stops spinning, your computer catches fire, there is some fuel around it, and it starts a chain of event that leads to the core of the nearest nuclear power plant melting down, I’ll have nothing to do about it.

Ok, so, first thing firsts: the ASUS P6T Deluxe V2 is a twelve years old motherboard but because it can use cheap 6-core / 12-threads LGA-1366 Xeons, available for as low as 15-20$ on AliExpress, is still hard to find and the prices are still high. Also, it’s a good platform for overclocking and it’s not that difficult to run a 2.5/2.6 GHz 6C Xeon at 3.5/3.8GHz stable. Extreme overclocking can lead top-tier Xeons up to 4.2 or even 4.5 GHz.
Thus, this motherboard is not cheap on the used market.
It just happens that I bought one new in 2010, along with an i7-930 – a 1st gen Core i7 from Intel – that I replaced for an X5650 and then for an X5660, currently on the board, but not overclocked (anymore). The case I used back then is the same as now, a Chieftec Dragon, which by today standard is a pretty old design.

Let’s get to fan speed.

This motherboard has 5 fan headers in total: 1 4-wire (PWM) for the CPU, 3 3-wire for the case fans and 1 3-wire for the PSU fan (whose speed cannot be adjusted).

I currently have four chassis fan connected to the system, all by Arctic Cooling: a front intake 80mm F8, a pair of intake 92mm F9 on the side panel (using a fan cable splitter) and a rear exhaust 120mm F12. None of these are PWM, they’re regular 3-pin fans.
The fan are connected as follows:
front F8 → CHA_FAN1 header
side F9s → CHA_FAN3 header
rear F12 → CHA_FAN2 header

The fan speed can be adjusted by the BIOS or the Operating System
* BIOS: This motherboard support the so-called Q-Fan feature on both the CPU and the chassis fan, and I’ve enabled it, using the “Silent” profile.
* OS: Under Windows there is the well-known ASUS Fan Xpert tool (but I suppose SpeedFan would have worked as well).

With the BIOS control, in silent mode, fan are quieter… but not so much. Both the front and side fans were spinning at around 1300 rpm even with the CPU completely idle at 30°C.

Under windows, with Fan Xpert, I was able to further reduce the fan speed to around 700/800 rpm at idle.

Under Linux… well there are quite a few problems to solve.

The first one is the ASUS ATK0110 driver. As much as I like ASUS motheboards, I’ve never – ever – understood the purpose of this driver.

Mint is “smart” enough to load this driver – asus_atk0110 – automatically so with the use of the lm-sensors package you can have access to temperatures, fan speeds and voltages. Install xsensors and you can even see them in a “nice” GUI application with a “very cool” 1995 feel (all those quotes are there for a reason, you know?).

The only problem is that if you attempt to run pwmconfig to control the fan speed, as reported in many guides, it tells you that there are no pwm-controllable fan in the system (which is kinda true, as the only PWM fan is the cpu one, but I’m not gonna control it, I’ll leave that to the BIOS as it’s not so loud after all). That’s because ATK0110 is something… well… not exactly defined. You find the “same” driver more or less on any ASUS product, from cheap laptops to workstation-grade motherboards, but there are different incarnation of the device and the related driver.

So, thank you Mint for loading the driver automatically, but… let me just use another one.

A quick series of “apt install”s, just to be sure everything is installed and up-to-date:

# apt install lm-sensors xsensors fancontrol

Similarly to what I’ve already done by editing a file “by hand” for lm-sensors (you can copy the content of this file and put it in a file like /etc/sensors.d/ASUS-P6T-Deluxe-V2):

# libsensors configuration file for ASUS P6T Deluxe V2
# ----------------------------------------------------

chip "w83667hg-*"

label in0 "Vcore Voltage"
label in3 "+3.3 Voltage"
label in2 "AVCC"
label in7 "3VSB"
# label in8 "Vbat"

set in2_min 3.3 * 0.90
set in2_max 3.3 * 1.10
set in3_min 3.3 * 0.90
set in3_max 3.3 * 1.10
set in7_min 3.3 * 0.90
set in7_max 3.3 * 1.10
set in8_min 3.0 * 0.90
set in8_max 3.3 * 1.10

label fan1 "CHASSIS1 FAN Speed"
label fan2 "CPU FAN Speed"
label fan3 "POWER FAN Speed"
label fan4 "CHASSIS2 FAN Speed"
label fan5 "CHASSIS3 FAN Speed"

label temp1 "MB Temperature"
ignore in8

After a quick check to be sure the correct driver has been loaded:

# lsmod | grep w83627
w83627ehf 49152 0
hwmon_vid 16384 1 w83627ehf


After running pwmconfig, you can customize the /etc/fancontrol file as follow:

# Configuration file generated by pwmconfig, changes will be lost
INTERVAL=10
DEVPATH=hwmon2=devices/platform/w83627ehf.656 hwmon3=devices/platform/coretemp.0
DEVNAME=hwmon2=w83667hg hwmon3=coretemp
FCTEMPS=hwmon2/device/pwm2=hwmon3/temp2_input
FCFANS= hwmon2/device/pwm2=hwmon2/device/fan1_input
MINTEMP=hwmon2/device/pwm2=35
MAXTEMP=hwmon2/device/pwm2=75
MINSTART=hwmon2/device/pwm2=80
MINSTOP=hwmon2/device/pwm2=75
MINPWM=hwmon2/device/pwm2=75
MAXPWM=hwmon2/device/pwm2=235

The result I obtained is the following (just ignore the ‘qlcnic’ temperature sensors of the network card):

And now the system is so much quiter (not silent, as it wasn’t my original purpose) than before that it’s reasonable to work on it.
This blog post was written on the PC in question after all.

Bye

… and you want to run an ASP.Net Core application on it (be it a web API, an MVC project or whatever).
Suppose you have a supported model, like a model 4B Pi with 8 Gigs of RAM (seems familiar? Well maybe…).

If you’re fine running Kestrel and accessing it directly on port 5000, good for you. Just look at the Microsoft docs on how to set up a Systemd unit to have your app run automatically at startup and you’re good to go.

But maybe you want to run Kestrel behind a reverse proxy, like nginx.

Cool.

Again, for a simple configuration where your app runs at the root of the site, the Microsoft docs are actually fine. They also instruct you on how to forward the headers from nginx to Kestrel and how to modify your application accordingly.

But maybe you want to run your app as a subdirectory (subdirectory, not a subdomain, which should be a simpler task, as the app will reside at the root of the subdomain) of your main site.

Cool, but there are some caveats.

The first one is that missing a single trailing ‘/’ in the configuration file of nginx makes the difference between a working configuration and a non-working configuration.

After some trials and errors I got to the following sample configuration file (which is the “default” file in the “sites-available” / “sites-enabled” directory from which nginx read it’s config) .

server {
        listen 80;

        index index.html index.htm index.nginx-debian.html;

        server_name your-raspberry-name.your-domain;

        location / {
                root            /var/www/html;
                try_files       $uri $uri/ =404;
        }

        location /apps {
                alias           /var/www/apps;
                try_files       $uri $uri/ =404;
        }

        location /apps/your-app-name/ {
                proxy_pass              http://localhost:5000/;
                proxy_http_version      1.1;
                proxy_set_header        Upgrade $http_upgrade;
                proxy_set_header        Connection keep-alive;
                proxy_set_header        Host $host;
                proxy_cache_bypass      $http_upgrade;
                proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header        X-Forwarded-Proto $scheme;
        }
}

The part of interest is, of course, the ‘location /apps/your-app-name/’ (in my case, my app is located in a sub-subdirectory because… why not?) section.
Notice the trailing ‘/’s in both the location and the proxy_pass directive.

But as I wrote, there are some caveats, not just one.

The second caveat is that, as the app is running in Kestrel, it thinks it’s running at the root of the site, not in a subdirectory (which tecnically is true, from a certain point of view). If you have an MVC app or a SPA which tries to load assets (stylesheets, scripts, images, etc.) from the path it believes it’s running from, it will fail. The result will be a crippled app, where the page will load without any asset (or, in the case of a SPA, it will not load at all).

After a lot of googling and reading every q&a on Stack Overflow even remotely related to this problem, I finally found a comment by Scott Hanselman on some random github issue that pointed me in the right direction (to be honest, that comment also pointed to the correct page to the related Microsoft docs).
The solution consist of a whopping 4 (yeah… four) LOC that have to be put inside the ‘Configure’ method:

app.Use((context, next) => {
    context.Request.PathBase = new PathString("/apps/your-app-name");
    return next.Invoke();
});

of course the argument of the PathString constructor can be retrieved from a configuration file or whatever, but for clarity sake, I have hardcoded the string in this example.
Notice the missing trailing ‘/’ in the argument.

With those two configurations I got a sample app (an app created from one ot the standard templates) running as expected inside a subdirectory with nginx and Kestrel.

Bye

… and you want to run PostgreSQL on it.
Suppose you have a model 4B Pi with 8 Gigs of RAM.
Considering that, up to fall 2019, I was maintaing some actively used business web applications on a 2 vCORE, 4GB of vRAM Windows Server 2008 R2 VM on which were running:

• SQL Server 2008 R2 – not exactly a lightweight RDBMS
• IIS
• a bunch of ASP.Net and ASP.Net Core applications (some of which were really bad performers)

I would say that a 1.5 GHz quad core ARM CPU and 8 GB of DDR4 RAM are more than enough to run PostgreSQL – and even some Kestrel istances – for some small home projects, if not for one small detail: storage.

I wouldn’t dare to run PostgreSQL on an SD card, so there are two options:

• an external storage medium (maybe a fancy USB3 SSD?)
• a network-mounted drive

I have a NAS at home, so the second option seems more practical.
Specifically I have a NAS that support iSCSI, so… why not? No file permissions to manage, block level access to the LUN…

So, first thing I did was to configure a LUN on the NAS and expose it as an iSCSI target: takes a total of 2 minutes, while drinking coffee.
Then I tought it was as simple as following any guide about open-iscsi on Debian… or not?

Well, in my case, after executing as root (after installing the open-iscsi package):

# iscsiadm -m discovery -t st -p ip.of.my.nas

I got three result, with the same target (i mean, the same iqn) exposed to three different IP addresses… two of which are on subnets not reachable by my raspberry (having a NAS with multiple interfaces is funny!).

To prevent some strange errors at boot, I decided to go (as root) inside the /etc/iscsi/nodes/##nasIdentifier##/ and delete everything with an ip different from the one I wanted to connect to.
Note that the content of the /etc/iscsi/nodes directory is written by the iscsi-adm utility.

The last step I performed to automatically connect to the iscsi target at boot was to modify the default file inside the /etc/iscsi/nodes/##nasidentifier/ip.of.the.target,3260/ directory and set

node.startup = automatic

at the next reboot I had a /dev/sda device available, which was the LUN of my iSCSI target.
Using GParted i created a partition on the device and then created an fstab entry to automatically mount it at boot (always remember to use the _netdev flag in fstab when dealing with network devices, like iSCSI, SMB, NFS, ecc.).

The fun starts now…

I wouldn’t enter the details of installing PostgreSQL on Debian, configuring it for at least the postgres user or setting up the pg_hba.conf and postgresql.conf to allow for access to the server via network.
After moving the data directory to a directory created on the iscsi mount, the following behaviour started to happen:

at boot, PostgreSQL failed to start -according to systemd – but when checking with

# systemctl status postgresql

after login, the result was that postgresql was running, but a quick

netstat -tuna

told a different story: no process was listening on the 5432 port.
But, when doing a

# systemctl restart postgresql

everything was back to normal and PostgreSQL was happily listening on its port.

after having a lot of fun reading the output of

journalctl -xe

I found out the problem was (you already guessed, right?) that PostgreSQL was trying to start before the iSCSI initiator had finished connecting to the iSCSI target.

As

# systemctl list-dependencies

Shows that the postgresql.service unit starts after the remote-fs.target, this shouldn’t happen.
Also, after editing the unit file for PostgreSQL with

# systemctl edit --full postgresql.service

by adding the following line

After=open-iscsi.service ##name-of-the-unit-for-remote-fs-mount##.mount

Nothing changed at the next reboot.

Looking better at the output of journalctl, I discovered an interesting fact: there are two units for PostgreSQL (and only one is shown by the “list-dependencies” command of systemctl… that little S.O.B.).

The unit postgresql@11-main.service is responsible for starting the PostgreSQL cluster, which is the one trying to access the files before the mount point is ready.

So after editing the correct unit by modifying the After line as following

After=network.target remote-fs.target

and adding the mount point of the data directory to the RequiresMountsFor line, at the next reboot PostgreSQL started normally and was already listening on port 5432 right after the Raspberry booted up.
I would say that there’s a lot of documentation about issues related to iscsi and postgresql… all related to CentOS and RHEL.
… lucky me, uh?

Bye

Just kidding of course, but I’m always puzzled by all the type of Intel’s stock coolers existing today.

Numbers doesn’t help much as they’re not used to code the type, features, etc. of the heatsinks.

So here they are…

(This is a continuos work-in-progress blog post: bear with it)

Unless otherwise specified, they’re all equipped with a 4 wire, 12Volt, PWM fan.

D34017-002: TBA

D34223-001: TBA

D60188-001: Your stock “Full-Height” LGA775 copper-core heatsink with a Delta fan (mine came with a Core 2 Duo E6600)

D95263-001: TBA

E18764-001: According to this Phoronix Review, this should be the stock “Low-Height” copper-core heatsink of the Core 2 Duo e8400.

E29477-002: Your stock “Full-Height” LGA1366 copper-core heatsink with a Foxconn fan (mine came with an i7-930)

E30206-001: TBA

E30307-001: Your stock “Low-Height” LGA775 copper core heatsink with a Foxconn fan (bought mine used… don’t know with which CPU was bundled)

E33681-001: TBA

E97379-003: have fun! This is a “Low-Height” LGA1150/1/5/6 all-aluminum heatsink with a Foxconn or Nidec fan
I have two of those: one came with an i3-6100, another with an i5-7500. Same number but slightly different heatsinks.

With the arrival from Hong Kong of the last adapter, I was finally able to finish my upgrade!

USB B panel mount connector

I enlarged the hole for the original cable and mounted there the panel connector. I can now use whatever USB cable (long or short) I like.

Joystick with USB B port mounted

In the end, this was, after all, a ‘test project’. I’m not gonna use this joystick a lot because… well, I just bought a Thrustmaster Hotas Warthog, and it’s worth every cent I paid.

In conclusion, what I learned from this project?

• When ordering more than one piece of electronic from eBay, especially from Hong Kong, it’s better to try everything when the items arrive, not just when one needs them.
• Without both good gimbals and good springs there is not a good joystick. I did this upgrade because I’m attached to this joystick as it was my first “good” flight controller like 17 years ago and I didn’t want it to stay on the bottom of a box with other useless things. I don’t recommend anyone to buy this joystick with the purpose of upgrading it like I did. Maybe it’s better to buy an FCS Mark II or an X-fighter (better gimbals and better springs if what I read it’s true).
• Cheap pots are cheap (Department of Redundancy Department here). What I mean is that I opted not to upgrade the pots with newer parts or hall sensors, partly because I’m lazy, partly because I think it was completely pointless (gimbals and springs). This means a lot of “garbage” on the analog inputs. Also, this means that the highest and lowest voltage levels change for various reasons (humidity, heat, planetary alignment…).
• Flight Simulators are a niche product nowadays but the community is still alive and is doing fine. Cheap $5 Arduino’s clones are extremely versatile. They’re great, really great. Making the electronic parts for a flight controller (sensors excluded) has never been this cheap.
• MMjoy2 is one hell of a software. It’s incredible, does everything, it’s free and open source (hosted on GitHub). I can’t be more grateful to the developer for making this fantastic work.

In the end,  my next project will be focused on the same upgrade to a Suncom F-15E Raptor joystick I bought used for €20. I’m also currently looking on eBay for old Thrustmaster TQSs (but the Hotas Cougar throttle it’s more appealing).

After all… it was fun. I’m not gonna use it very much, but I’m fine knowing I did this upgrade.

With two axis and one throttle the stick is suitable for a lot of activities (like flying a Cessna, with a set of rudder pedals), but not for military purposes. We need at least a trigger and a weapon release button (the trigger is used only for the gun, while the weapon release button, well release – or drop, or launch, or whatever – the selected weapon, except when the selected weapon is the gun) to use this joystick for combat sim.

Anyway, first things first: MMjoy2 allows two types of button’s connection.

• Buttons connected via shift registers (any number up to 128 per device or a little less)
• Buttons connected via button matrix (up to 100 via a 10×10 matrix but with some limitations because of the high number of I/O pins used)

If you want to connect a single button, you have to create a 1×1 matrix (silly concept, I know, but that’s the way it works). MMjoy2 guidelines states that over about 10 buttons, shift registers are the way to go. I agree, maybe not with 10, maybe over 16 I’d go with shift registers too.

Back to the Top Gun Platinum (by the way I’ve seen Top Gun – the movie – in a cinema recently for the 30 years anniversary! In – almost – 3D!), we have 4 buttons and a “China Hat” switch.
Let’s have a look to the “DASH 1” of the McDonnel-Douglas F-4E:

Stick functions from the TO 1F-4E-1

So we have the aforementioned trigger [TRG], weapon release button [WPR], an Air-Refueling Disconnect button [ARD] and a nose-wheel steering button [NWS]. Then we have the “China Hat” 4-way switch that is used for pitch and ailerons’ trim control.

In the Top Gun Platinum, as I already wrote in the first post of the serie, the hat switch was connected as an axis. I – more or less – destroyed the PCB under the switch to leave the four push buttons in the hat disconnected. Total numbers of buttons for the new configuration: eight.

After a quick glance at the MMjoy wiki to check how to connect the buttons in a matrix using as less cables as possible, I decided to go with a 2×4 matrix, 2 rows and 4 columns.

How to connect a button matrix to the MMJoy

The diodes are used to prevent ghosting and masking. I found a rather interesting article about those two problems with really simple to understand images. You can read more here [link]. For the diodes, I found eight identical signal diodes. They worked and so I decided to use them. 1N4148s are good to go.

Here is the grip with the new connections:

Inside the grip

Once the buttons were connected to the Arduino, I started to setup the MMJoy settings for the buttons:

MMJoy setup utility

The really good thing about MMjoy is that any button in the matrix can be assigned to any button on the device. For instance, I like to assign [TRG] to button 1, [WPR] to button 2, etc. Also, any button can be assigned to the “Hat” up-left-down-right press.

In the end, under Windows, this is a screenshot of the device check screen under Windows 10 control panel:

Windows 10 Joystick Control Panel

This pretty much sums up almost everything I’ve done. Next and final step will be about the finishing touches (but I’m still waiting for a pair of cables to arrive from Hong Kong).

Bye

With the arrival of two “Pro Micro” Arduinos from an eBay seller in Hong Kong (fast shipping, just two weeks, but one, unfortunately, is not working), work has started on the Top Gun Platinum!
My choice was to use the MMJoy2 firmware that is a really nice software. With MMJoy2 a compatible Arduino is seen as a HID device, so no drivers are needed and compatibility is assured 100% with every software. It’s a really powerful software and I really like it. Links here: MMjoy wiki (en).

Pro Micro Board

The first step (at least for me) was to re-wire the pots (potentiometers) for the two axis and the throttle. The older game port connection worked as an ohm-meter by measuring the resistance of the pots used as variable resistance. The ATMega32U4 integrated ADCs simply read a voltage value between 0 and 5 Volts, from pots, hall sensors, external sources. That means that the pots have to be connected between Ground and 5V (Power or USB +5V) with the cursor connected to one of the ADC pins.

Connecting inputs to the MMJoy2-programmed board

I decided to use wires from a CAT-5 Ethernet Cable for both the axis’ pots and the throttle’s pot.

Axis’ pots rewired with wires from CAT 5 cable

The throttle’s pot with the new wires

I also put some grease on the gimbals and on the throttle axis. I used some teflon grease that should last some years (I hope).

I then connected all the wires to a sort-of “shield” so I can easily swap the board, just in case…

Ghetto shield for axis connection

Just to make a simple test, I decided to close the base, leaving the board outside.

Board hanging outside the joystick base

And then a final picture before connecting the base to the PC to test the pots and their connections.

The base closed before a quick test

The quick test went fine. Next part will be about connecting the grip’s buttons and China HAT (POV) switch.

Bye

(Part 1 of X as, honestly, I have absolutely no idea of how many parts this series of articles will last, anyway).
Oct. 1, 2016 update: Part 1 of 4 😉

If you’re reading this you probably know which company Thrustmaster is, what’s its main business and what are their most known products. Probably you’re a simmer.

If you’re not a simmer, that means a person which is interested in simulation (usually flight simulation), then maybe you don’t know Thrustmaster. This is their website: Thrustmaster.com (US).

Some Thrustmaster products really made history and any good simmer knows them:

• Pro Flight Control Stick
• X-Fighter Joystick
• Rudder Control System
• Weapons Control System – a programmable throttle controller
• F-16 TQS and FLCS – full size programmable replicas of the F-16C’s throttle and stick
• F-22 PRO – a full size programmable replica of the YF-22 stick (almost exactly the same as an F-16C, F-22A’s stick is different)
• HOTAS Cougar – a renewed F-16’s HOTAS replica controller
• HOTAS Warthog – a replica of the A-10C’s HOTAS

Back on topic, around year 1998/1999 my father bought me a Thrustmaster Top Gun Platinum joystick. The original “Top Gun” (the joystick, not the movie) was an X-Fighter joystick with simpler gimbals and directly attached potentiometers (from now on pots for short). The Top Gun Platinum added a throttle to the base of the controller with an all-black colour style.

The joystick we’re talking about

The joystick model with a big logo of Paramount

And now some (interesting?) technical details:

• The stick is really similar to (but not exactly a replica of) a B-8 grip. The B-8 was a very widespread grip that was used on many US and NATO aircrafts, like the F-4 “Phantom II”, the A-10A “Thunderbolt II”, the Bell 206 “JetRanger III”, the Aermacchi MB-339 and many others.
• The stick, as usual for that time was connected via game port.
• It has 3 axis, four buttons and a four way “china hat” switch, usually used in simulators for changing the player’s Point of View (and therefore sometimes named HAT/POV) while in real airplanes is used for pitch and roll trim.
• Thrustmaster used a “hack” for connecting the hat switch on this and many other joysticks before USB became the standard connection. Because game ports allowed to connect a total of 4 axis and 4 buttons, and the hat switch usually is implemented with 4 microswitches, there was a shortage of buttons that can be connected. Thrustmaster used an axis line and some resistors to send various resistance values to the game port. An “ad-hoc” driver inside the game or the operating system decoded the resistance values and used it as if 4 different buttons were pressed. The drawback is that only “up”, “down”, “left” or “right” directions were allowed (both mechanically and electrically) as it wasn’t possible to combine two commands simultaneously.

Now the project itself is about completely rewiring the joystick and converting it to USB using a cheap Arduino reprogrammed as a HID device.

Part 2 of X will follow when work will actually start.

Bye

I’m doing some experiments with OpenWrt (http://openwrt.org), in particular, I need to build a custom firmware for a cheap router (a TP-Link WR-841N).
OpenWrt is modular enough to install packages on an already installed image, but when your flash memory size is 4MiB, you want to strip everything unnecessary and add everything you need inside the SquashFS file system.

Building a custom image doesn’t require recompiling anything, there is an ImageBuider package that just create the complete firmware image with a custom build script.

The ImageBuider package has been designed to run on an x86_64 Linux distro.

So I installed Centos 7.0 on Hyper-V on Windows 8.1, everything was working out great except for the screen resolution, that was stuck at 1152×864 (X.org is smart) in the Display Settings in Gnome, and my notebook display is 1366×768.
I would be pretty satisfied at running Linux with a resolution of 1024×768, it’s not that I really need 1366×768 at the moment, but even if 1024×768 is a lower resolution compared to 1152×864, X.org doesn’t allow to select any of the lower VGA, SVGA or XGA resolution.

It’s not that the VM is unusable, but it’s very frustrating dealing with scrollbars even in full-screen mode. The funny part is that Linux already include the Hyper-V integration services since kernel 3.3 or 3.4 or something like that and RHEL 7.0 currently use 3.10 (a giant leap forward from the 2.6.32 kernel of RHEL 6.x), but there was no way X.org recognized the Hyper-V framebuffer.

With the xorg.conf file gone a long time ago, we are in the era of autoconfig, monitor hotplugging, etc.

Microsoft state that the best way of connecting to a VM running in Hyper-V is via RDP, this requires having a stable network connection between the host and the guest OSs and having a RDP service running in the guest OS: pretty easy on Windows, a bit more complicated on Linux where xrdp, an RDP server, works but it’s not an easy solution and always require a stable network connection.
If the Hyper-V server is in the DataCenter, this surely is the best solution, but on a notebook this is a bit an overkill.

Looking at the output of lsmod, the hyperv_fb module is already loaded, so there is no reason for it not to work.

After following various guides with all the sort of commands, like adding a modeline to xrandr (doesn’t work), adding video=1366×768:24 to the kernel boot arguments (doesn’t work), adding resolution=1366×768 always to the kernel boot arguments (needless to say…), I’ve finally found the first alf of the solution in a forum about SUSE.

TL;DR

Adding in GRUB2 the kernel boot argument:

video=hyperv_fb:1366x768

finally allowed me to use the VM in full screen @ 1366×768!

Bye

A fast update just to say that the adapter is fully working on the Raspberry Pi running NetBSD 6.99.
Connection parameters are 115200-8-N-1 with flow control OFF (ON by default on PuTTY).
The adapter should work also on Rev. 1 Raspberry Pi B models, but there is no P6 (soft reset) header on that revision.

As standalone serial interface, works flawlessly with my old D-Link DSL-G624T wireless modem router. Being a rather old device, it use a slower 38400 bps connection (38400-8-N-1), but, nevertheless, works pretty well.

At last, just to leave no doubts about the SP3232 IC, as mentioned in this article (http://www.fullmeta.it/?p=379):

Sì, sono proprio quelli

Bye