recordmydesktop script

I've used recordmydesktop for grabbing the few desktop videos I need.

It's useful to record a specific window. This requires knowing the window ID beforehand, acquired by using xwininfo.

Remembering and executing this phase is sometimes a bit annoying, so I tried to shorten the process a bit by using the following script. I guess a front-end exists somewhere, though.

After running it, xwininfo is indeed launched but the info is directed through grep to a temporary file. I click on the window I want to record, the output is parsed so that the window ID is passed onto recordmydesktop.

It could be bit more elegant but what do I care.


#!/bin/bash
echo Click on Window
echo WILL RECORD INSTANTLY
echo using fps 30
xwininfo -display :0 | grep "id:" > temp.txt
more temp.txt | grep -Eo '0x[0-9]+' > temp2.txt
fname=$(<temp2.txt)
echo $fname
rm temp.txt
rm temp2.txt
recordmydesktop --windowid=$fname --fps 30

I noted that on occasions at least Chromium browser window refuses to work (unrelated to script I think). Recordmydesktop had trouble with the acquired window ID. First I thought it might have to do with detached tabs, but not really. Sooo... maybe just run another instance of it and try again or something.

Horizontal and vertical dual setup on Linux Mint

I have never really been a two-screens guy, unless you count the inevitable retro computer monitor next to the modern PC.

Partly because there's never ever enough desk space to do that, partly because I've felt that having my eyes wander between two wide screens is too un-ergonomic, and so on and on.

On a whim I noted I could at least save some desk space by having the other screen as vertical. This would also reduce the horizontal eye and head movement.

Reading news sites or Facebook it might be a better layout, as many websites are now designed with a vertical screen in mind.

But it's still more of an excuse to get the second monitor fit.

To me it makes sense to have a vnc window to another computer on this second monitor. No, really, although it does sound a bit silly.

I've occasionally tried running two computers on two monitor side by side, and found that to be more confusing than the vnc. I have more than two computers and so the keyboard/mouse sharing options could get complicated. Plus the other computers might not be stacked physically close to the screen.

So, I could get used to this.

Connecting two screens and changing their orientation is not at all difficult in Linux Mint/Mate. Some challenges arise from trying to do specific things.

The primary monitor is connected with DVI, whereas the other is on a Displayport->VGA adapter. (I don't have a displayport-equipped monitor) The primary monitor is 1920 x 1200 and the secondary as 1680 x 1050 (1050 x 1680)

It may not be obvious that by moving the pink and cyan rectangles changes the way the mouse pointer crosses over to the other screen.

I did encounter some hiccups in the way the icons are arranged on the primary screen. When trying to match the screen positions with the physical reality, some icons went over the top of the desktop and would not "arrange" correctly either.



Drawing with a Wacom tablet on screen 2

Using GIMP window in one screen and tools in another, is not something that works well for me. The mouse pointer transitions between monitors are not ideal and shifting my focus is even less so.

But, drawing on a vertical format on a single screen might make sense in Krita or Mypaint.

Generally I've found my cheap-end Wacom tablet to behave well in Linux.

The first instinct of the tablet device is to map the entirety of the display range to the tablet. Just like if you take a screenshot it will mosaic both screens. This makes sense if you thing the tablet as a substitute for a mouse, but it's not good for drawing.

xrandr can tell the names of the screens (or the ports?) such as DVI-D-0 and DP-2 in my case.

xsetwacom --list devices will tell the names of the tablet devices:

Wacom Intuos S 2 Pen stylus      id: 12 type: STYLUS    
Wacom Intuos S 2 Pad pad        id: 13 type: PAD  

But, instead of using the screen names from xrandr, I found that using HEAD-0 and HEAD-1 work instead. (I've understood this is due to Nvidia drivers. Just in case the above works better I've included the info).

xsetwacom set "Wacom Intuos S 2 Pen stylus" MapToOutput HEAD-1

What still remains is that the scaling is all wrong because the tablet is horizontal and the screen is vertical!

xsetwacom set "Wacom Intuos S 2 Pen stylus" rotate ccw

This rotates the orientation counter-clockwise. "none" and "half" are also possible values. Obviously the physical tablet will have to be rotated too.

After removing the window toolbars it's quite nice to draw on Krita vertically.

After these settings, everything works as I'd expect: the mouse still works across both monitor boundaries, whereas the Wacom tablet is limited to that one screen with Krita.

There is a discrepancy between the color and intensity and gamma of the two monitors, which can be annoying in some situations but I may even need that in some visual tasks, looking at how a graphic might show in different environments.


Launching applications

I recall this has always been a bit off-putting with the Mint Mate dual monitor set up. The thing is, programs don't launch in the correct monitor in a logical way.

Part of the confusion may be that it is all treated as a single display after all.

Some programs, like Krita and GIMP, remember the previous configuration, which is great.

I don't expect to play Steam games etc. in this vertical monitor so that can be forgotten. I already recall this required some fiddling and is partly to blame for my negativism towards two-monitor setups.

Half-Life 2:Lost Coast behaves rather nicely, but the mouse is mapped wrong

But there's really no need to force games, or films, to play on that vertical monitor.

I created a panel to the second monitor with application launchers. This might help with obvious ones such as the terminal window.

Even this information I had to dig up somewhere: The new panel can be only created on a monitor with an existing panel. Drag the new panel to the correct monitor with ALT pressed down.

Using compiz and and changing compizconfig settings does not help, although some of the options sound like they might address this issue.

Looking around, this launching problem seems like a fairly persistent issue with Mint.

I could make this somewhat kludgy script, make a launcher icon run it and technically have my application run on the other monitor:

#!/bin/bash
x64 &
sleep 2; wmctrl -r "VICE: C64 emulator" -e 0,1920,0,1200,1500

But it's not especially ideal either, here the "sleep" period is used so that wmctrl can catch hold of the window.

Should I want to run Vice full screen then it will again switch to the primary monitor. Ok, if I add the -fullscreen argument to x64, the script will miraculously run it full screen on the other monitor, but the pointer will be confined to that screen. Vice seems to do that in any case, so that's the end of that really.

It does not matter to me if Vice runs full screen on a wrong shaped monitor, I'm simply using this as an example of the kind of problems that may arise from this setup if you insist on getting something to run on the 2nd screen.

Going through a lot of software and finding out they don't behave in the best possible way gives a negative feeling, even if I wouldn't really even use those apps on the second screen.

So, the "wrong" monitor launch is not an enormously big deal, more like an annoyance that comes from testing multiple apps. 

1541 Ultimate II

Finally I got the Ultimate cartridge for the C64.

Not the II+ mind you, but a second hand version of the II, with the tape emulation add-on and the Ethernet-USB dongle thrown in.

The adapter has the label "NO:usb 2.0 LAN JP208 MADE IN CHINA" and that's all I know of the brand and make of it. It's good to have an already proven solution included.

Firmware upgrade

I didn't really buy the cartridge for the Ethernet functions, but I was curious enough to want it to work. It happened the u1541 firmware was 2.6 and needed upgrading before this would work well. In any case it must be a good idea to update the firmware.

At this moment I realized the Ultimate cartridge, despite being highly rated and professional-looking hardware, has a rather scattered and a bit confusing documentation. Well, it's quite common for any of these hobbyist add-ons. As I got this second hand the docs may have been lacking.

So, an upgrade 2.6 version to 3.07beta needs an update.bin file in the root folder of the SD card (Usb stick is not enough). When booting, the update will run.

Afterwards, I could upgrade using u2u files. (I guess u2p files are for the plus) When I had my 3.4c version going, I could finally see the IP address on screen.


Remote control and file transfers

Now it's possible to telnet to that IP from another computer, using port 23.

PuTTy is fine, but correct settings are needed for display and cursor keys and backspace.

Initially arrow keys or function keys did not work without pressing Control at the same time. Changing PuTTy keyboard settings to VT100+ helped. "Initial state of cursor keys" is "normal".

Local echo and local line editing are both "force off". Backspace is set to "Control-H"

Also, the font did not display correctly despite changing it from UTF-8 to ISO-8859-1:

I fiddled with various settings, but apparently I needed to untick the box that says "override with UTF-8 if locale says so".

After this it started working properly:

The telnet connection is quite impressive and it's nice to have the remote for viewing files in quick succession. The software inside the cartridge does not care what state the C64 is in, so the menu can be operated all the time the power is on.

ftp is also possible, but any attempts to integrate it to caja (the Linux mint file browser) were not especially successful. I could see the folder but file transfers failed. The same with filezilla, a file manager, which seemed so convoluted I wouldn't probably use it even if I found the correct settings.

Instead, I got it to work using command line ftp to the IP address. First use 'binary' to set all further file transfers to binary, otherwise files will be sent with incorrect file lengths. (despite the system saying its switching to binary for the files.)

'ls' gives the remote folder contents. 'cd SD' is likely the first move, to get to the root folder of the drive. Then 'put' puts a file on the local current folder to the current remote folder, and 'get' does the reverse. 'bye' exits the ftp command line.

Apparently the telnet and ftp functions don't mesh together, so you can't upload a file using ftp while "in" with telnet.

Edit: Apparently they could work together, but it's just that messing back and forth multiple times with either ftp or telnet tends to lock the cartridge. A script that sends a file on ftp and launches it via telnet, may work one or two times. This could be related to a bug/oversight in the cartridge.


Some fooling around

One of the main functions of u1541 is the utility cartridge collection. For the purposes of using the cart for running files and general compatibility, the Retro Replay cartridge seems to be the standard.

But there are others, such as Final Cartridge III and my old friend Action Replay VI.

For fun, I did a code snippet on the monitor. (Invoked by MON).

Well, the monitor is in the Retro Replay version of the cart too.

AVI was the original environment where I learned the first steps of assembler in the early 1990s.

For a long time these were the last steps too, because I didn't understand how to structure these programs at all.

Now I see that it would be possible to write long programs using the monitor, giving enough room for subroutines and using a meticulous paper documentation/mapping.

There is another interesting cart, the Turbo Action ROM by Soundemon/Dekadence. This contains Turbo Assembler:

So the same code snippet can be written this way. The source can be assembled by pressing arrow left (the "esc" key, not the cursor key) followed by 3.

After assembling the source, the cart can be reset, and after activating the Tasm again the source is still in place. (If it's not overwritten I guess).

Perhaps this would have been helpful back in the day. However I must say that it would be really painful to write long sources with this one and writing code directly in machine code monitor might even have some advantages compared to an assembler. There were of course various techniques for splitting the code, and in the end it might require the kind of forethought and paper mapping as with the monitor.

Overall

The core functions of the cart are supreme and I probably won't look too much back at SD2IEC and IRQHack.

Yet, it seems the cart is trying to be a bit too many things, yet some obvious things are missing (if I'm not wrong). Effort has been put into areas that are not that interesting to me, like printing or some weird audio extensions.

For example, from what I've read and experienced, the cartridge does not seem to allow straight-up transfer+execution of the transferred file. You have to manually launch the ftp-transferred file from the menu. This doesn't sound a lot, but it's an unnecessary step and a more direct result would been better for building and executing code.

This is something the IRQhack could do (although again in a limited way) and I don't see a reason why the Ultimate would not if the software was put into place. Maybe I am wrong and the function is there somewhere.