Page 2 of 7
Re: DM-1701 screen clipping
Posted: Tue Jan 23, 2024 11:16 pm
by VK3KYY
HA5DS wrote: ↑Tue Jan 23, 2024 11:07 pm
Now that the source code if available I could finally do it, the radio feels so much better to use.
Since the DM-1701 does not have GPS, and the GPS status does not needs to be displayed in the status bar, I could make all fields a little more spacious.
The DM-1701 has a very big display compared to the other radios, so the Channel display had plenty room even if I added 12 pixels at the top. I just had to rearrange some elements. I did not touched the menu and other pages, I think that can be skipped, but the channel screen was very important, now I think it's so much better.
1701_dmr_after3.png
What did you change to fix this in the source code ?
i.e Did you change the position of everythng or make a change to the XY offset in the data transfer to the display?
Re: DM-1701 screen clipping
Posted: Tue Jan 23, 2024 11:52 pm
by ct1esj
HA5DS wrote: ↑Tue Jan 23, 2024 11:07 pm
Now that the source code if available I could finally do it, the radio feels so much better to use.
Since the DM-1701 does not have GPS, and the GPS status does not needs to be displayed in the status bar, I could make all fields a little more spacious.
The DM-1701 has a very big display compared to the other radios, so the Channel display had plenty room even if I added 12 pixels at the top. I just had to rearrange some elements. I did not touched the menu and other pages, I think that can be skipped, but the channel screen was very important, now I think it's so much better.
1701_dmr_after3.png
Well done boy. All DM-1701s have a lot of space on the display, and it is properly structured. I would like, and I assume many more owners, to see this structure in the next update. Glad someone got the display fix. THANKS
Re: DM-1701 screen clipping
Posted: Tue Jan 23, 2024 11:55 pm
by VK3KYY
ct1esj wrote: ↑Tue Jan 23, 2024 11:52 pm
HA5DS wrote: ↑Tue Jan 23, 2024 11:07 pm
Now that the source code if available I could finally do it, the radio feels so much better to use.
Since the DM-1701 does not have GPS, and the GPS status does not needs to be displayed in the status bar, I could make all fields a little more spacious.
The DM-1701 has a very big display compared to the other radios, so the Channel display had plenty room even if I added 12 pixels at the top. I just had to rearrange some elements. I did not touched the menu and other pages, I think that can be skipped, but the channel screen was very important, now I think it's so much better.
1701_dmr_after3.png
Well done boy. All DM-1701s have a lot of space on the display, and it is properly structured. I would like, and I assume many more owners, to see this structure in the next update. Glad someone got the display fix. THANKS
We will fix this problem if the solution is practical
i.e In the code the location of most texts is defined and can be changed for different types of radios, but sometimes the position of a specific piece of text is offset from another piece of text, so sometimes simply changing the 'defined' positions causes one screen to be fixed but other screens to be broken.
Re: DM-1701 screen clipping
Posted: Wed Jan 24, 2024 9:42 am
by HA5DS
VK3KYY wrote: ↑Tue Jan 23, 2024 11:16 pm
What did you change to fix this in the source code ?
i.e Did you change the position of everythng or make a change to the XY offset in the data transfer to the display?
Well, for now I only changed the code, so it would work for me, but since the DM-1701 has its own firmware, I see no reason why it cannot be done.
I modified the define constants to move the text locations, and these are defined like this:
Code: Select all
#elif defined(PLATFORM_MD380) || defined(PLATFORM_MDUV380) || defined(PLATFORM_DM1701) || defined(PLATFORM_MD2017)
#define DISPLAY_H_EXTRA_PIXELS 32
#define DISPLAY_H_OFFSET (DISPLAY_H_EXTRA_PIXELS / 2)
#define DISPLAY_V_EXTRA_PIXELS 64
#define DISPLAY_V_OFFSET (DISPLAY_V_EXTRA_PIXELS / 2)
#define MENU_ENTRY_HEIGHT 16
#define SQUELCH_BAR_H 9
...
So the same values are used for 4 platforms, this can be separated, so the DM-1701 could have it's own values.
Most of these defines were in the
uiGlobals.h file, there were 2 values for the VFO sweep graph in
uiVFOMode.c.
There are also a couple of the in
uiUtilities.c file.
I also needed to modify the code a little bit, because even though the position of the texts in the header was defined by these constants, the inverted rectangle of the mode text (FM/FMN/DMR/etc.) was fixed starting from position 1,1.
Also the
uiUtilityRedrawHeaderOnly function needs to redraw 3 rows now, not 2.
Re: DM-1701 screen clipping
Posted: Wed Jan 24, 2024 10:12 am
by VK3KYY
HA5DS wrote: ↑Wed Jan 24, 2024 9:42 am
VK3KYY wrote: ↑Tue Jan 23, 2024 11:16 pm
What did you change to fix this in the source code ?
i.e Did you change the position of everythng or make a change to the XY offset in the data transfer to the display?
Well, for now I only changed the code, so it would work for me, but since the DM-1701 has its own firmware, I see no reason why it cannot be done.
I modified the define constants to move the text locations, and these are defined like this:
Code: Select all
#elif defined(PLATFORM_MD380) || defined(PLATFORM_MDUV380) || defined(PLATFORM_DM1701) || defined(PLATFORM_MD2017)
#define DISPLAY_H_EXTRA_PIXELS 32
#define DISPLAY_H_OFFSET (DISPLAY_H_EXTRA_PIXELS / 2)
#define DISPLAY_V_EXTRA_PIXELS 64
#define DISPLAY_V_OFFSET (DISPLAY_V_EXTRA_PIXELS / 2)
#define MENU_ENTRY_HEIGHT 16
#define SQUELCH_BAR_H 9
...
So the same values are used for 4 platforms, this can be separated, so the DM-1701 could have it's own values.
Most of these defines were in the
uiGlobals.h file, there were 2 values for the VFO sweep graph in
uiVFOMode.c.
There are also a couple of the in
uiUtilities.c file.
I also needed to modify the code a little bit, because even though the position of the texts in the header was defined by these constants, the inverted rectangle of the mode text (FM/FMN/DMR/etc.) was fixed starting from position 1,1.
Also the
uiUtilityRedrawHeaderOnly function needs to redraw 3 rows now, not 2.
OK
For this to be usable a new section would need to be defined for PLATFORM_DM1701 and also the other places would need to have #if defined(PLATFORM_2017) around them
BTW.
The reason there is a function called RenderRows is because the radios with black+white screens have the screen divided into sections of 8 rows becuase of the way the 1 bit data is organised. And because the UI code is almost completely unified across black+white and colour screen radios, then the renderrows function is retained even though its not applicable to the colour screen radios.
Probably it should be replaced with a function like RenderLines which calculates the Row from the Line for black+white radios, but no one has time to retrospecively clean the code, especially as changing code can accidently introduce bugs
Anyway.
When you finish, can you zip the files from the application directory, and I can do a file compare and determine whether there is a way to implement this without affecting the layout of the UV380 and the other radios which share the same codebase, or the other radios which use the shared UI code i.e probably all the radios including GD77 and MD9600 and now MD2017
Re: DM-1701 screen clipping
Posted: Wed Jan 24, 2024 10:35 am
by HA5DS
VK3KYY wrote: ↑Wed Jan 24, 2024 10:12 am
OK
For this to be usable a new section would need to be defined for PLATFORM_DM1701 and also the other places would need to have #if defined(PLATFORM_2017) around them
When you finished, can you zip the files from the application directory, and I can do a file compare and determine whether there is a way to implement this without affecting the layout of the UV380 and the other radios which share the same codebase
Sure, I will do that.
Another thing I did, which I think it's worth considering for all models, is that I specified another background color for the background of the RSSI bar, rather than the background color of the header. That way it's a little bit more distinguished from the header itself, I like this look better.
Of course if somebody doesn't, it's always possible to set to the same value as the header even if it's a separate theme option.
Right now I did this with a quick and dirty solution, I used the GPS spot option in the Theme Editor, since the DM-1701 does not have GPS, and this way I didn't need to add a new theme option everywhere.
But I think it's worth considering doing that.
Re: DM-1701 screen clipping
Posted: Wed Jan 24, 2024 10:42 am
by VK3KYY
HA5DS wrote: ↑Wed Jan 24, 2024 10:35 am
...
Another thing I did, which I think it's worth considering for all models, is that I specified another background color for the background of the RSSI bar, rather than the background color of the header. That way it's a little bit more distinguished from the header itself, I like this look better.
I do not know if this will be practical. There is very limited space available for these additional data blocks e.g the theme data
Daniel wrote the theme data system, and I don't know whether he used all available space
Also, the way the extra data (e.g theme data) is stored, is complex, and not designed to handle changes to sizes of data structure
Re: DM-1701 screen clipping
Posted: Wed Jan 24, 2024 7:33 pm
by F1RMB
Just moving down the header offset is not enough, you will get visual problem, as the header has 16 pixel height, past this it won't really work (like RSSI rendering).
Changing the screen scheme is not an easy task, because you should not break all other supported platform, and also don't harrass the MCU/BUS too much.
Re: DM-1701 screen clipping
Posted: Wed Jan 24, 2024 8:25 pm
by HA5DS
F1RMB wrote: ↑Wed Jan 24, 2024 7:33 pm
Just moving down the header offset is not enough, you will get visual problem, as the header has 16 pixel height, past this it won't really work (like RSSI rendering).
Changing the screen scheme is not an easy task, because you should not break all other supported platform, and also don't harrass the MCU/BUS too much.
Yes, of course I needed to move down the RSSI bar as well, and also the TG display, etc.
I also needed to check to whole code, how many rows we are updating on the display and why, and does it needs to be changed, or not.
This is a before and after screencap of the DMR display:
- 1701_dmr_before.png (3.33 KiB) Viewed 554 times
- 1701_dmr_after3.png (3.2 KiB) Viewed 554 times
Re: DM-1701 screen clipping
Posted: Wed Jan 24, 2024 9:53 pm
by F1RMB
I'm talking about rendering, not drawing.