- Now writes a command to the R8180REG_EEPROM register to allow the
R8180REG_CONFIG3 register to be written. When that command was missing,
writing to the R8180REG_CONFIG3 register only succeeded when
R8180REG_EEPROM already had the right value by chance, perhaps from a
previous opening of the device (the same command was written to
R8180REG_EEPROM later in the initialisation code for another purpose).
Furthermore, subsequent writing to the R8180REG_ANAPARAM* registers
requires the write to R8180REG_CONFIG3 to succeed, so those registers
were also not always initialised. Therefore, radio initialisation only
succeeded intermittently, and as this problem was not detected or
reported by the code, the device silently failed to send or receive any
radio data on many openings.
- Removed duplicate and possibly too early enabling of transmission,
reception and interrupts.
- Also patch the signal bit of the control pipe's message port ahead of
each access to the pipe, not just the task. This fixes instability when
the pipe is accessed from a task other than the one that initially opened
the unit.
- Don't use CreateMsgPort() to allocate the message port used for control
pipe access. We won't use the signal it allocates and the task that
allocates the unit may not be the one that deallocates it (which could
lead to the wrong task's signal being freed upon DeleteMsgPort()).
- Renamed msg_port to control_pipe_port.
Move working function to new LVO. Note that declaration was made public
on 22nd August so between then and now there was correct declaration
referring to function at old LVO. There were no SDK release after that
date so the problem was not made public.
These classes are still considered WIP, the Panel.mui conflicts with
existing MUI4/5 Panel.mui class which has different role and the
attributes are using MUI attribute space instead of AROS attribute space.
The general idea would be to move these classes to separate external
custom classes.
MUIV_Frame_XXX define frames of a components (like frame of a group or
a button) not frame shape. In MUI developer cannot upfront define the
shape of an element. He defines a function (a button) but the shape and
other visual aspects are defined by the user using Zune preferences.
Those structures are argument to bsdsocket.library or miami.library
function call. Take great care when updating them. Other structure in the
public headers are considered internal and their changes cannot break
existing user-land programs.
Also document when 'long'/'ulong' variables are used and this changes
sizes between 32-bit and 64-bit.
Public are all headers needed to build AROS and contrib for user software.
Specialized software like dhcp, ping etc will need also internal headers.
This allows to decrease the exposure in public SDK and allows for easier
changes of stack in future. Note that not all structure in the public
headers are actually exposed. Consult the README.txt for list of really
used structures.
This way the library can be filtered out when linking .ko objects for
m68k ROM. If it's not filtered out, it's functions are getting copied to
each .ko blowing up their size which causes to run out ROM space.
libcodesets is part of LIB_SPEC of gcc. It needs to present otherwise
isolated contrib build with pre-compiled cross-compiler will not trigger
it and will fail.
This part of structure is documented as private but it is still in public
SDK, so who knows if any of the following fields are not accessed by
some code. It also doesn't cost us anything to have these two fields
back in the structure.
