Category: Uncategorized

I guess I should preface this by saying that Lenovo recommends that you do not install Windows 10 on the N581.

Well this is a little bit of a different post. I just thought I’d document this little hardware issue that I encountered and had to solve.

So the situation was that after I got the November Update for Windows 10 on my Lenovo N581 the Wifi stopped working.

The solution is to update the BIOS.

I got the BIOS Updater from the Lenovo site (they make a habit of changing the URL for their support pages, so if the link is dead just navigate to their support page from lenovo.com).

For reference the device description and hardware IDs on my machine were
Broadcom 802.11n Network Adapter
PCI\VEN_14E4&DEV_4727&SUBSYS_058714E4&REV_01
PCI\VEN_14E4&DEV_4727&SUBSYS_058714E4
PCI\VEN_14E4&DEV_4727&CC_028000
PCI\VEN_14E4&DEV_4727&CC_0280

The updater was called 5ecn96ww.exe and my previous BIOS version was 3.06 and it updated to 9.01.

Just be aware that after it flashes the new version it will reset your settings. I was still using MBR Boot with GRUB, so it didn’t boot anymore after the update. I had to go into the BIOS settings and disable EFI again for the device to boot again.

But after that everything was fine again and the fan seems to kick in a lot less now. So good tidings all around.

Hope I could help someone find the solution to their problem (I know I searched the net fruitlessly for an hour).

This is just an account of my first experiences with Emscripten and this is empatically not a tutorial for ,or review of emscripten.

Smooth sailing period

So I started to make a small test-game with SDL2 and thought I’d try to compile with emscripten. So I downloaded the Windows SDK and since I didn’t have a CMake or other unixy compatible Makefile for the project yet I just made a unit-build like *.cpp that includes all *.cpp files to compile.

Just doing the “em++ -I../src unity.cpp” got surprisingly far, it had some issues with some SDL Functions though. I imagine it to be because it presumes SDL1.2 instead of SDL2. So searched for whether it SDL2 was available for emscripten as well.

Some bumps in the road

It was, in source form. After downloading the source my problems started. The build-instructions for SDL-emscripten told me to use “emconfigure ./configure […]” which didn’t work under Windows since it couldn’t find any executable named “configure”.

Alright, so that was a no-go. But there was another suggestion to do the configuration with “emconfigure cmake”. This failed for me because I accidentally tried to execute that inside the source tree, which just gave me an error about it. Since I didn’t want to hunt for all the configuration files to delete, I just unzipped the SDL source tree again and corrected my error.

While CMake now generated project files successfully it was sadly VS2013 project files, which naturally don’t work at all. So I had to switch the CMake generator to “MSYS Makefiles” to hopefully get something useful. CMake again happily obliged to generate Makefiles. Now just to open my MSYS shell and type “make” right? Not quite, the *.bat files to set up the environment variables to get emscripten to run didn’t work in bash for obvious reasons and the *.sh file that was in the emscripten directory just called some other *.sh files that were nowhere to be found. Well that’s enough of that, I got the message. Windows isn’t really suited to run these tools that are primarily designed for UNIX like environments.

“Well, I’ll just try my Linux Laptop then” I thought to myself a little spitefully. There downloading the SDK files wasn’t an issue either, but the installation entails compiling LLVM clang which took a little while. In fact such a while that I started writing this blog post in the meantime.

Back on track?

“Alright, so this should be easier” I told myself. I was not quite without issues though. For some reason it tried to call nodejs by “node” but my Ubuntu distro only had it under the name “nodejs” so I had to install a legacy package that created a symlink (not that I couldn’t make the symlink myself, but this way it gets cleaned up if I ever remove nodejs).

Getting “something” to compile was taken care of after that. It was just linking that was a problem now. Curiously linker errors are just warnings with emscripten (presumably because you can patch those in at runtime in Javascript). It took me quite a while to figure out that using “em++” to link didn’t work. So I had to compile with “em++” and link that resulting obj-file with “emcc” to get it to cooperate.

That was a good waste of a Saturday.

So I happened to implement multi-touch for PPSSPP and to do that I consulted the Windows documentation which made me request touch input with RegisterTouchWindow and then handle the resulting WM_TOUCH events, the only issue is that Windows still sends the emulated WM_LBUTTONDOWN WM_MOUSEMOVE and WM_LBUTTONUP, so I needed to filter the events that came from touch to not handle them twice.

The docs recommendeded I filter with

#define MOUSEEVENTF_FROMTOUCH 0xFF515700
#define MOUSEEVENTF_MASK 0xFFFFFF00
//...
//...
case WM_LBUTTONDOWN:
if ((GetMessageExtraInfo() & MOUSEEVENTF_MASK) != MOUSEEVENTF_FROMTOUCH)
{
//handle mouse events here
}
break;
case WM_TOUCH:
//handle touch here

But turns out this silently makes pen inputs disappear in a black hole as they trigger MOUSEEVENTF_FROMTOUCH but don’t generate a WM_TOUCH event. So I added the 0x80 bit to the mask which is 1 when the source is touch and 0 when the source is a pen/stylus.

#define MOUSEEVENTF_FROMTOUCH_NOPEN 0xFF515780 
#define MOUSEEVENTF_MASK_PLUS_PENTOUCH 0xFFFFFF80
//...
//...
case WM_LBUTTONDOWN:
  if ((GetMessageExtraInfo() & MOUSEEVENTF_MASK_PLUS_PENTOUCH) != MOUSEEVENTF_FROMTOUCH_NOPEN)
  {
    //handle mouse events here
  }
  break;
case WM_TOUCH:
  //handle touch here