Partial answer: The xmodmap mapping actually works correctly. As xev shows, you get keysym 0xffbe which is F1, as it should be.

So the question is (1) why it still changes brightness and (2) why it returns the keycode 232 (for KEY_BRIGHTNESSDOWN) instead of the one for the F1 key (67).

For (1), I suspect Ubuntu runs something by default the reads directly from /dev/input instead of processing X events, and this is processing the key no matter what xmodmap says. You didn't say which desktop environment you run (Gnome?). You can look with lsof for a process that directly reads the /dev/input/eventX source (you got the number X from evtest, numbers can change across boots). You can also test this theory by running evtest --grab /dev/input/eventX: This will make evtest the exclusive program to process the events, so when you press Fn+F1, it should still show KEY_BRIGHTNESSDOWN, but the brightness of your PC/Laptop screen should stay the same.

As for (2), googling the brand name shows it's a Bluetooth keyboard. This means it's likely a HID device. You can debug the by looking at dmesg to identify the corresponding hidraw device file and the bluetooth identifier. Then do

mount -t debugfs none /sys/kernel/debug

as root, and have a look at sys/kernel/debug/hid/*/rdesc for the correct device (look at available subdirectories). If you can't make sense of it, put it in a pastebin and edit the question with the link. Also, dump raw HID events using hexdump -C /dev/hidrawX, pressing Fn and F1, F2 etc several times. That should give you an idea why the kernel translates this the way it does.

Partial answer: The xmodmap mapping actually works correctly. As xev shows, you get keysym 0xffbe which is F1, as it should be.

So the question is (1) why it still changes brightness and (2) why it returns the keycode 232 (for KEY_BRIGHTNESSDOWN) instead of the one for the F1 key (67).

For (1), I suspect Ubuntu runs something by default the reads directly from /dev/input instead of processing X events, and this is processing the key no matter what xmodmap says. You didn't say which desktop environment you run (Gnome?). You can look with lsof for a process that directly reads the /dev/input/eventX source (you got the number X from evtest, numbers can change across boots). You can also test this theory by running evtest --grab /dev/input/eventX: This will make evtest the exclusive program to process the events, so when you press Fn+F1, it should still show KEY_BRIGHTNESSDOWN, but the brightness of your PC/Laptop screen should stay the same.

As for (2), googling the brand name shows it's a Bluetooth keyboard. This means it's likely a HID device. You can debug the by looking at dmesg to identify the corresponding hidraw device file and the bluetooth identifier. Then do

mount -t debugfs none /sys/kernel/debug

as root, and have a look at sys/kernel/debug/hid/*/rdesc for the correct device (look at available subdirectories). If you can't make sense of it, put it in a pastebin and edit the question with the link. Also, dump raw HID events using hexdump -C /dev/hidrawX, pressing Fn and F1, F2 etc several times. That should give you an idea why the kernel translates this the way it does.

Edit

Looking at the hidraw dump, the keyboard correctly produces scancodes 3a, 3b etc. for the function keys, as described in the HID descriptor.

So the problem must be in the HID-to-input translation layer.

You can interrogate this layer via ioctls. There's no public tool for this I know of, but I may put one up on github when it's done.

The only way to set this mapping I know is via the udev hwdb database as described e.g. here.

So I would guess who have some package installed that provides a database entry to map F1 to brightness control, and that also provides a program to react to this by directly monitoring /dev/input/event*. Try to see if you can find it on your system. lsof may help.