A Review of New Laptop: HP Envy x360 13 (2020)

So I finally have new replacement over my old ASUS A456UR laptop which I used for more than 3 years. Here's my old laptop specifications:

• Intel Core i5-7200U
• NVIDIA GT 930 MX
• 8GB of DDR3L RAM (not quite sure for the type actually). It was come with 4GB soldered RAM.
  
• 512GB of SATA SSD. It was come with 1TB hard drive which now I repurpose as external drive.
• 1366x768 screen, NTSC

And here's my new laptop specifications:

• AMD Ryzen 7 4700U
• 16GB of DDR4-3200 RAM (both soldered)
• 512GB of M.2 SSD. I have plan to upgrade it to 1TB later, but it's not my priority at the moment.
• 1920x1080 screen , 98% sRGB
• Touchscreen and stylus support, 360 degree hinge
  

From gaming perspective, this is a downgrade since my previous laptop had NVIDIA Optimus but from my overall perspective, it's overall upgrade (the 16GB RAM and the 8-core processor is important). I also ended up picking AMD because they have nice reputation nowadays and I don't want to fall into this Intel driver problem. Furthermore Genshin Impact doesn't play well with Intel GPUs/drivers.

NOTICE: Consider performing clean install when you get the laptop after you reedemed the Office Home & Student and Dropbox Promotion (if available).

First Impression

My first impresion, this laptop is quite small. It's interesting to see a smaller laptop have better specs than bigger laptop. This laptop also has Windows 10 and Office 2019 for free (although the latter may not available depending where you ge tthe laptop, ask the store first!) so I don't have to use cracked version of those which was my case for the old laptop (that I eventually reinstalled to ArchLinux).

Booting speed is fast. I don't have to see any moving circle loading indicator and it just straight boot into the lock screen, or is it just be first time experiencing laptop with M .2 SSD. The screen is also bit yellow, but quick search shows that sRGB tends to bit yellow due to its white point stands at 6500k.

It has some bloats which you can simply uninstall. For example: I'm not a fan of McAfee so I uninstalled it, thus Windows will switch back to its built-in Windows Defender. It also comes with Dropbox promotion (may vary depending on stores) which I simply reedem to my dummy Dropbox account then uninstall. There's probably one most important app that you'll most likely use: The HP Command Center. This one controls the thermal profile of the laptop. Because the laptop has aluminium chasis, it can be uncomfortable to touch on long CPU (and GPU) stress usage.

Battery Life

The battery life is simply amazing. I often use the laptop unplugged and it's enough to attend 2 consecutive online class which both can lasts for 2 and half hours. At night, it lasts for 5 hours and that even still left me with 25%.

Performance

8 cores without SMT is fine. Definely an upgrade from my previous laptop (2 cores + SMT). I feel significant speedup on compiling Android projects, transcoding, and everything in general while still being efficient. There's one thing to note however: if you're pushing the whole cores to 100% (i.e. video encoding) then you need to take care of the thermal. If you're using the laptop in air-conditioned room then it's fine to leave the thermal profile on performance. Otherwise you'll most likely need external fan.

Touchscreen & Stylus

The touchscreen and the stylus functions okay, not perfect. For some reason, the touch input and the stylus input has jittery/wavy lines, so the pen can only used for coloring or quick writing at best. Some reviewers said it's MS Pen Protocol to blame however. You also need to press slightly harder for the stylus input to register. For the touch problem however, I don't think it's a problem and it's a plus point on having touchscreen because I can test touchscreen-specific code in my LOVE projects.

 

(seek to 2:01 to see what I'm talking about the jittery thing)

Bluescreen

If you encounter bluescreen with SYSTEM_THREAD_EXCEPTION_NOT_HANDLED message pointing to msgpioclx.sys when performing full shutdown (restart also counts), then it's most likely the WiFi driver. Simply rollback the Realtek WiFi driver to resolve the issue. If it gets installed again, then use Windows Update Minitool to blacklist/hide the driver update.

UPDATE: If you encounter Live Kernel Event without bluescreen (screen just blank then restarts), then it's the AMD driver to blame. Downgrade to 27.20.11044.7!

Genshin Impact

Why do I even put this? Well fine.

The game recommends medium settings. Mind you, the game runs with integrated graphics and the default recommended settings can run the game at 30 FPS. I prefer 60 FPS so I can simply turn off motion blur and set the render to 0.8.

Default graphics setting.

Again, make sure to have external fan or playing in air-conditioned room and set the thermal profile to performance. Otherwise you're risking the laptop to overheat. There was one case where I overheated the laptop, resulting in force shutdown. At that time, I opened Android Studio, Photoshop, and Genshin Impact at same time since I need to get some information from the game and put it to Android Studio for my assignments.

There's only one annoyance I found however. When I restart the laptop or after a day, the game logged me out from my game account, forcing me to login again. This never happends in my old laptop and in my phone. Maybe it's just because I copied the game files from my old laptop and used the launcher "Locate Game Files" option instead of fully downloading the game from scratch. I'll update this section once I have solution.

UPDATE: Reinstalled the game at 1.5. Problem still occurs sadly.

UPDATE2: Disabling "HP Support Solutions Framework Report" task at "Task Scheduler/Helwett-Packard/HP Support Assistant" seems helped on the random logout. You'll still logged out when performing restart/full shutdown however.

UPDATE3: I'm currently "playing ping-pong" between their customer service to get this problem fixed. I ended up offering myself to assist fixing the issue. Not sure how it will goes (or maybe not).

UPDATE4: I ended up performing clean install and so far the problem no longer occurs, but there's no vendor-specific apps installed yet.

Additional Notes

• The laptop screen support AMD FreeSync between 40 and 60 FPS.
• You need to charge the stylus first.
• Careful when opening the pen box. I accidently spilled two stylus heads inside the box because I opened the box wrong way. I found both back however.
• It defaults to "Action Keys Mode". Pressing "F" function keys runs the respective action icon instead (i.e. pressing only F4 toggle the keyboard backlit). This can be changed in UEFI setting.
• It comes with multi-port hub with USB Type-A, Type-C, and HDMI, one for each.
• Anything on the keyboard won't function when you flip the laptop more than 180 degrees. This includes the power button and the fingerprint. This can be annoying when the screen turned off by Windows and it automatically locks.

Conclusion

 I think that's what you need to know. Whetever you want to get this laptop or not depends, but my suggestion is to wait for the Ryzen 5000 series

... because those has SMT too.

Bad Apple in CMake: How it Works?

There are already lots of Bad Apple videos played in various things. Start from Minecraft and Command Block, Minecraft Sheep color, and even in your terminal. I'm interested with the latter, but the one I linked uses C. I don't think someone ever do this and I'm probably become the first one to do so. So I present you Bad Apple video player written in CMake. This blog post will explain in-detail how it works, but before we dive deep into the CMake script, there are some things need to be noted.

1. CMake is slow. In my laptop, it can display the frames at 2.8 FPS. The video above is speed up.
2. I use braille unicode characters. This allows me to encode 2x4 pixels width in a single braille character. Also Wikipedia has extensive documentation of which bits to set to activate dots in braille characters.
   
3. The videos are converted to PBM. Why PBM? Because Bad Apple PV is black-and-white and because it's very simple to parse compared to PGM or PPM. As PBM packed all pixels to bits, where the MSB is the first pixel, this means it's possible to display 8x4 pixels of the image using only 4 braille characters.
   

Now, open the CMakeLists.txt file as points below will be highlighted by line number.

1. The first few lines is not that important. They already explained in the comments. The "PRINTER_MODE" condition will be explained later, so just skip to line 138.
2. At line 138, I look for FFmpeg executable. FFmpeg is used to convert the Bad Apple video into PBM frames.
3. Line 142 to 158, I look for youtube-dl. youtube-dl is used to download the Bad Apple PV from YouTube.
4. Line 163, download only the video. I use add_custom_command so the downloaded video is marked as "generated" which allows it to have file-level dependency later on.
5. For line 169 to 183, there are 6572 frames that's marked as "generated". That 6572 files depends on 1 file, which is the video. This is why I said "file-level dependency". Notice at line 181 I added "VERBATIM" because I need to pass that percent sign as-is. (Reason: Windows doesn't like it)
   
6. Then at the line 186, I define a target "BadApple". This will be the target that should be run and it depends on that 6572 frame files. Thus, the order of execution is: download the video, convert to 6572 frames, then run the specified command. If you inspect the command, it literally just run again CMake at the current source directory, but it sets the "PRINTER_MODE" to truth value and sets the "FRAME_PATH" variable, thus let's get back to line 22. You can quickly search up the "CMAKE_*" variables I use in the internet. It should be in the first page.
   
7. Line 26 is the braille character that the CMake will use for display.
8. Line 51 is a function that takes 5 arguments: the result variable name, then followed by the value of a byte in the PBM. That function will shift the bits to fits with braille unicode encoding bits (see https://en.wikipedia.org/wiki/Braille_Patterns#Identifying,_naming_and_ordering for more information). I think an image will explain it better.
   
   
   
9. More explanation on line 51, that means BYTE1 is used to determine whetever dots 1 or 4 will be turned on. BYTE2 is used for dots 2 and 5. BYTE3 for dots 3 and 6. Finally, BYTE4 for dots 7 and 8. The formula is bit confusing to read due to parentheses and brackets everywhere.
   
10. Line 63, a helper function that allows me to index an image byte by its X byte position and Y position. Note that it multiplies the index by 2 later on, that's because the whole PBM data is read as hex.
    
11. Line 83 is escape character, building block of the ANSI escape codes of setting cursor position later on.
12. Line 85 is to loop all the 6572 frames and display it one by one.
13. Line 87, read the PBM image data directly as hex (because binary data). It's actually possible to calculate the offset by getting the string length of WIDTH and HEIGHT, but I'm lazy.
14. Line 90 to 95 is basically the "Playback" text which displays the current second and minute of the video. Bad Apple PV runs at 30 FPS so 30 FPS is assumed.
15. Line 99 and 102 is to loop over every image pixels (except at x axis where we process 8 pixels at a time).
16. Line 104, now the image at point 8 makes sense. BYTE1 through BYTE4 contains the value of the packed image pixels,
17. Finally at line 119, it prints the PBM image data as braille characters using CMake's message function and sets the cursor up, ready to be overwritten by the next braille characters.
    
18. And at last, at line 124, it sets the cursor to the end and finally the function finishes.

Fun fact: I cut and speed up the videos only with FFmpeg since Kdenlive encoding options result in poor video quality (and my laptop native resolution is only 720p). The total recording duration of the video is 41 minutes and 4 seconds

... or equivalent to Bad Apple PV played 11 times plus quarter.

What To Do in Case Hyper-V "Default Switch" is Missing or Disappear?

Starting my laptop today, I noticed that in my Task Manager, the "Default Switch" adapter has disappeared from the network adapters. Then I noticed that I can't ssh to the Hyper-V VM I setup few days earlier. This quite puzzled me because as turns out the ArchWSL I setup with WSL2 also failed to start, and this error flooded my event viewer. As a side note, the VM starts fine, but it doesn't have any network at all.

Tried to delete Hyper-V feature and reinstalling it back, issue still persist. sfc /scannow, "Windows protection did not find any integrity violations". So one best guess is that somehow removing Hyper-V doesn't remove all the network switches configuration. Time to do something dangerous.

Strong Notice: Steps below is dangerous to do. Consider creating system restore point prior performing steps I mentioned below. You'll also lose all your Hyper-V VMs (and all Virtual Switch configurations) so ensure you have exported your VM beforehand.

1. Be prepared for lots of reboots.
   
2. Uninstall Hyper-V and all its related components. In optionalfeatures.exe, untick Hyper-V, Virtual Machine Platform, and Windows Hypervisor Platform. Unticking Windows Subsystem for Linux is not needed (despite using Hyper-V for WSL2). Then, click reboot.
   
3. Open regedit.exe, then navigate to HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\vmsmp\parameters\SwitchList and delete all subkeys there. Same goes to NicList above SwitchList, remove all subkeys.
4. Reboot
5. Repeat step 3 until there are no more subkeys.
6. If you deleted some values in step 5, reboot.
   
7. Go to C:\ProgramData\Microsoft\Windows\Hyper-V, you may need to take the ownership of that folder, don't worry. Windows Explorer will ask you to do so in 1 click of a button.
8. Delete everything in that folder.
9. Reboot
10. Repeat step 3 and 5 again
    
11. Do the reverse of step 2, including the reboots.
    
12. After the system boots up for a while, open elevated powershell and command prompt. In the elevated powershell, type "Get-VMSwitch". This one should hang, don't worry. Then in the elevated command prompt, execute "sc start hns".
13. Wait for a moment, then you should see "Default Switch" back in Task Manager. And the elevated powershell window should return values (no longer hangs).
14. Reconfigure your network switch if needed
15. Import back your VMs.

I don't quite remember the steps but that's what I've been done. Now WSL2 starts again and I cna ssh back to the VMs after I imported it.

What a blog post to start 2021

https://knowyourmeme.com/photos/1918696-disappointed-black-guy

... unless it shows 34 December 2020 instead

LÖVE on Windows 10 ARM64 Part 3: We're Going ARM64

LÖVE 12.0-development branch running in Windows 10 ARM64 under QEMU.

This is the moment of truth, and this is will be the last part of my LÖVE on Windows 10 ARM64 blog post series (part 1 here, part 2 here). In short, it's possible.

The long answer however, require various patches. Most of the patches went into external libraries that LÖVE needed. The timeline of these is simply by these recent commits, but an explanation each of them are as follows:

The first thing to do is to update SDL to 2.0.12, apply Megasource-specific patches, then apply this patch so it compiles under VS2019 because screw MSVC generating calls to memset and memcpy even when you specify /NODEFAULTLIB! Next is to update OpenAL-soft up to the recent commit for MSVC ARM64 support (see my previous blog post, I mentioned about OpenAL-soft there) then re-apply Megasource-specific patches.

The next library is bit tough and this is where most of my time spent. Ogg and Vorbis is the most annoying one that I start to suspect this is CMake bug (I use 3.19.1, the latest as of writing). I updated Ogg and Vorbis to 1.3.4 and 1.3.7 respectively, and for some reason I got error that reads "cannot open input file 'ogg.obj'" for "liblove" and "megatest" targets. Looking at the project configuration using Visual Studio shows that"ogg" is referenced twice in those both targets. I unfortunately went to last resort by using Megasource-provided CMake for both projects and the problem went away. To be honest, I have no idea why that happends, and I'm kind of sure that using Megasource-provided CMake may gives inferior performance because it uses generic, non-architecture-dependent code. Anyway it's solved so let's move on.

The last change is to Megasource CMakeLists.txt itself. There are various changes there that needs to be explained (I'll be using green-highlighted line number).

• Line 20: Add variable for detecting ARM64 compilation. Currently, it only works for MSVC + Visual Studio targets but this is sufficient for my needs at the moment.
• Line 155 and line 171: Unfortunately, as of CMake 3.19.1, their InstallRequiredSystemLibraries module doesn't support MSVC ARM64 and it will pick x64/AMD64 DLLs instead, so those lines will supress copying the MSVC redistributable libs when compiling for MSVC ARM64.
• Line 242: SDL will try to load OpenGL32 in Windows first then trying other backends. This gives me bit puzzle when prototyping my patches because even setting LOVE_GRAPHICS_USE_OPENGLES=1, SDL_RENDER_DRIVER=opengles, and
  SDL_OPENGL_ES_DRIVER=1 environment variable has no effect, so I went into last resort and tell SDL not to compile the OpenGL backend instead. This is fine, LOVE will run using OpenGLES codepath using ANGLE.
  
  

  

  SDL fails to find OpenGL32.dll in Windows 10 ARM
  

• Line 270 and line 332: LuaJIT doesn't support Windows 10 ARM64 yet, so Lua 5.1.5 bundled with the Megasource must be used. This is actually a performance impact but if even the LuaJIT interpreter can't compile (let alone the JIT compiler) then it's impossible to use LuaJIT there unless Mike adds support for it. This also increases fragmentaton because people who uses LÖVE are used to bitwise library provided by LuaJIT, but a possible fix for this is to bundle LuaJIT's LuaBitOp within Lua 5.1.5 or LOVE (when LuaJIT is not used).

After applying patches to Megasource, now patches in LÖVE are as follows, and mostly related to its buildsystem and dependencies instead:

First, tell LÖVE not to link to OpenGL. While Windows 10 SDK for ARM64 provides OpenGL headers, it doesn't include OpenGL library which cause link errors in later step. This is fine and there are no noticeable problems whatsover (even in Windows x64 builds) because LÖVE will use SDL to load OpenGL(ES) functions anyway.

The next is PhysFS, which is easy fix, and I have plan to report that later on. The last problem is dr_mp3 used in LOVE 12.0. dr_mp3 and dr_flac doesn't expect this compiler and platform combination so I have to report this problem to upstream for a proper fix (which for dr_flac, doesn't compile error so that one can wait). This is why this blog post is slightly delayed.

Afterwards, LÖVE will compile and you can install and push it to your Windows 10 ARM64 machine (or QEMU) and see LÖVE runs there. Currently I can't provide binaries at the moment because the automated GitHub Actions that's supposed to compile LÖVE binaries via artifacts is failing for some reason and quick search shows that it's OpenAL-soft to blame. So an update to prebuilt binaries will probably come in another blog post or edits in this blog post instead.

Speaking of ARM64, someone also managed to compile LÖVE for Apple Silicon

 ... which is related to this blog post title.

LÖVE on Windows 10 ARM64 Part 2: One Step at A Time

 

OpenAL-soft test program I wrote running in Windows 10 ARM64 under QEMU

So I have few news that I want to share. First, OpenAL-soft now complies for Windows 10 ARM64. LÖVE depends on OpenAL for high performance audio backend (even the -soft version of OpenAL developed by kcat is fast enough), so getting this compiles for Windows 10 ARM64 means one step forward to bring LÖVE on Windows 10 ARM64. And the last is Microsoft released OpenGL driver built on-top of Direct3D 12 for Windows 10 ARM. This probably sounds that my effort of making weekly binaries of ANGLE using GitHub Actions is useless but actually no. Compiling ANGLE is bit data-intensive so people will just prefer getting binaries.

Since I've successfully able to run Windows 10 ARM64 under QEMU, this blog post will wrote about it.

The first thing that comes to my mind when installing this is picking good tutorials. I found this tutorial (click here) is good as it provides all the necessary drivers, firmware, and EFIvars needed, although I have to source the .iso myself, but I already did that beforehand.

As the tutorial said, it's slow as dirt at i7-4770K, so it's safe to assume that it's even slower than dirt at my laptop, i5-7200U (okay it has dGPU but it's irrelevant for this). I had to do the setup multiple times with multiple strategies just to make it get past OOBE and I think I killed around 120GB worth of SSD writes because this.

My first method is basically naive method. Automatic graphic installer, then proceed as Microsoft intended. This doesn't go well because I can't get past OOBE and then it just automatically restart then stuck in restart loop (which forces me to redo the install again). I retried this multiple times with different CPU (from 2 to 4 CPU) and RAM (from 2 to 4GB) configuration with no avail, so my conclusion is I need to look for other methods.

Because my problem is related to OOBE, it makes me wonder if I can somehow skipped it. I don't quite remember the whole progress of this, but what I remember is I installed Windows 10 kinda "manually". I searched on YouTube about Windows 10 hacks by Enderman and found an interesting video of installing Windows 10. Basically instead of installing via GUI, just install it from command prompt.

First time I tried the method, it result in unbootable OS (blue screen with INACCESSIBLE_BOOT_DEVICE). That's because the "manual" install method assume no additional drivers needed to detect the disk. Unfortunately in my case, I need to add RedHat VirtIO driver prior installing so it can detect the disk (see tutorial link above at step 9). Well even when I installed the drivers manually via DISM, it still result in endless boot loading icon, so I erased the whole install again.

Finally, the method I found to be working is this. First, install the Windows 10 as usual (from the ISO). After the first-phase install finished, I boot back to the setup ISO then open command prompt there (Shift+F10). At this command prompt, I installed the RedHat VirtIO with "pnputil" command, then mount the partition back with diskpart. Afterwards, I just follow along the YouTube video above starting at 0:56 (no need to type the bcdboot command!). For the last part, when the video says wait for 5 minutes, I actually waited for hours. First attempt of this failed so had to redo again, but then I found it works when I simply "reset" the emulator just when it shows the login screen.

Afterwards, jsut tick the privacy thingy then you're ready to use it. You need to alter the registry again to kill OneDrive setup tho because running x86-emulated binaries there is too slow to the point that installing VS2019 redistributable is impossible because no window pops up (let alone OneDrive setup). For additional performance, this tips (click here) really helps alot on making sure the CPU stays idle and not spin at 100% continously.

That's how I got Windows 10 ARM64 running under QEMU in my laptop. And of course I'll continue this blog post when I have progress.

... and if you want to read the previous blog post, please click here.